A mapping layer for filesystems

Posted May 10, 2018 18:20 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: A mapping layer for filesystems by ringerc
Parent article: A mapping layer for filesystems

Yes, I understand that. I still think it would make much more sense to add a "Hey, can you increase your size?" request to the iSCSI/whatever block devices rather than: "I pinky swear that I'm REALLY using this space".

This way you don't need to have untested failure paths that can happen at any moment.

A mapping layer for filesystems

Posted May 11, 2018 0:14 UTC (Fri) by dgc (subscriber, #6611) [Link]

> I still think it would make much more sense to add a "Hey, can you increase
> your size?" request to the iSCSI/whatever block devices

Read the article again - that's essentially what the infrastructure I was talking about provides us with.

i.e. it provides us with the ability for the filesystem to request the amount of space it needs from the underlying storage before it starts doing operations that depend on that space being available. Hence if the device does not have space available, then the filesystem can back out and report ENOSPC to the application before getting into a state it can't sanely recover from if it receives device-based ENOSPC errors during IO....

-Dave.

A mapping layer for filesystems

Posted May 29, 2018 16:12 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

That's why first thing you should do after getting such fake space is dd if=/dev/urandom of=/file. This would give you some guarantees that your space you need is there. And should avoid unpleasant surprises in the future.