Re: adding linux syscall fallocate

[Jason Thorpe <thorpej%me.com@localhost>]

> On Nov 18, 2019, at 1:13 PM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
>> Now, what happens if you do a posix_fallocate("foo", 0, 4GiB)?  The file sys$
> 
> Given the intent of posix_fallocate as I understand it, that's the only
> reasonable option for FFS.  If a filesystem has a way to record a block
> that should read as zeros but is allocated in the sense that a block is
> guaranteed to be available to back writes, then, maybe.  But are there
> any such?  (See below.)

Yes, for FFS and its on-disk format, there isn’t really much else to do.  That is true for MOST file systems, actually, not just FFS.

>> Technically, a file system is allowed to make that optimization for the "all$
> 
> Speaking from an FFS perspective....
> 
> All you need is a second magic block number.  Block number zero is
> already reserved for holes.  Making, say, block number 1, or -1, or
> some such, reserved to represent "block-of-zeros semantics for which
> all backing data has been accounted as allocated", so that writing such
> a block is guaranteed to have space available?

If you’re using a single magic block number for “allocated, but uninitialized”, how are you supposed to know where to write data when the user comes along to initialize it?  If it were me, I’d probably just go with the strategy of using a signed 64-bit file system block number, and use a negative number to indicate allocated-but-uninitialized ... for an FFS-like file system that uses direct / indirect block pointers, anyway.

Indirect blocks don't really complicated things much at all ... they would continue to work as they do now... it's only the leaf blocks that point to actual file data that need to be handled specially.

-- thorpej