Re: [PATCH RFC 7/8] xfs: return non-zero blocks for inline data

[Carlos Maiolino <cmaiolino@redhat.com>]

> > > > > > > Inodes with inlined data should actually report 0 blocks, otherwise,
> > > > > > > many
> > > > > > > applications which actually relies on the amount of allocated blocks
> > > > > > > for each
> > > > > > > file will misbehave.
> > > > > > > 
> > > > > > Man ls(1) reads:
> > > > > > 
> > > > > > -s, --size
> > > > > >       print the allocated size of each file, in blocks
> > > > > > 
> > > > > > So the 'ls -ls' would report 0 blocks when the data is inlined, a file
> > > > > > holds data
> > > > > > but it consumes 0 blocks, how is it possible :),
> > It is possible because the file doesn't consume data blocks at all.
> > 
> > > > > This patch is inspired by the
> > > > > upstream commit 9206c561554c9 (ext4: return non-zero st_blocks for inline
> > > > > data),
> > > > > please refer it for details.
> > > > The fact that we're following precedent set by ext4 is worth mentioning
> > > > in the commit message.
> > The fact another filesystem use this trick, doesn't necessarily means it's
> > correct. Ext4 added it to workaround a issue with tar, which actually skip zero
> > blocks files. I honestly think it is wrong, we are working around a user space
> > problem, which is wrongly assuming a 0-block file is empty.
> 
> The assumption which deemed 0 block files as empty holds true until the
> kernel broke the
> rules and introduced inline data feature, so the user space should not be
> blamed in my opinion.

Did we? I couldn't find any interface, design, or whatever saying that userspace
can safely assume a zero block file don't have data there and can be ignored,
in fact, the link I posted previously already shows how tar people were not sure
if they should assume a zero block file could be ignored. So, in fact, we didn't
break anything, because as far as I know, nobody and no standard said an
existing zero block file could be safely ignored, assuming it contains no data
at all. Such thing might exist, but I'm not aware of.

> 
> > A quick search led me to this thread from tar project:
> > 
> > http://www.mail-archive.com/bug-tar@gnu.org/msg04209.html
> > 
> > 
> > Anyway, as I said, my opinion only, I do really think reporting a single block
> > used by inlined files is wrong, and if we are going to do that, we should at
> > least properly document this is being done to workaround user space issues,
> > while, in the meantime, it might create others.
> 
> Faking block usage count is not quite correct one but the sad fact is that
> there are applications
> out there which are designed and implemented on the assumption that non-zero
> length files
> consume at least a block, so I don't think breaking the user space suddenly
> by reporting 0 blocks
> for inline data is not a correct solution either.
> 

I understand, and yeah, we fell into some kind of chicken-egg problem, I still
do think though there are not that much applications out there assuming
zero block files are empty, and working around bad coded application which make
assumptions they are not supposed to make, is as bad as breaking applications
for not following standards, which will end up punishing applications which do
not make assumptions they should.

The biggest drawback I can see by reporting 0 blocks allocated for inline files,
might be while estimating space needed for a copy, or a backup for example,
where, if the target filesystem does not support inlined data, 0 blocks files
will occupy at least a block on the target filesystem, but the same holds true
when source and target filesystems have different block sizes.

Anyway, that's all the arguments I have against faking block usage for inlined
files, but the final decision is not mine :)

Cheers

-- 
Carlos