Re: udf: Suspicious values in udf_statfs()

["Pali Rohár" <pali.rohar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

On Friday 17 January 2020 12:38:33 Jan Kara wrote:
> On Thu 16-01-20 16:30:19, Pali Rohár wrote:
> > On Monday 13 January 2020 13:08:51 Jan Kara wrote:
> > > > Second one:
> > > > 
> > > > 	buf->f_files = (lvidiu != NULL ? (le32_to_cpu(lvidiu->numFiles) +
> > > > 					  le32_to_cpu(lvidiu->numDirs)) : 0)
> > > > 			+ buf->f_bfree;
> > > > 
> > > > What f_files entry should report? Because result of sum of free blocks
> > > > and number of files+directories does not make sense for me.
> > > 
> > > This is related to the fact that we return 'f_bfree' as the number of 'free
> > > file nodes' in 'f_ffree'. And tools generally display f_files-f_ffree as
> > > number of used inodes. In other words we treat every free block also as a
> > > free 'inode' and report it in total amount of 'inodes'. I know this is not
> > > very obvious but IMHO it causes the least confusion to users reading df(1)
> > > output.
> > 
> > So current code which returns sum of free blocks and number of
> > files+directories is correct. Could be this information about statvfs
> > f_files somewhere documented? Because this is not really obvious nor for
> > userspace applications which use statvfs() nor for kernel filesystem
> > drivers.
> 
> Well, I can certainly add a comment to udf_statfs().

Adding comment directly to udf_statfs() would really help.

> Documenting in some
> manpage might be worth it but I'm not 100% sure where - maybe directly in
> the statfs(2) to the NOTES section? Also note that this behavior is not
> unique to UDF - e.g. XFS also does the same.

I think it make sense to write these information into statfs(2) manpage.
And specially if this is implemented in more filesystems. Also this
structure is exported into statvfs(3) call too.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]