Re: udf: Suspicious values in udf_statfs()

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

On Monday 13 January 2020 13:08:51 Jan Kara wrote:
> Hello,
> 
> On Sun 12-01-20 17:23:11, Pali Rohár wrote:
> > I looked at udf_statfs() implementation and I see there two things which
> > are probably incorrect:
> > 
> > First one:
> > 
> > 	buf->f_blocks = sbi->s_partmaps[sbi->s_partition].s_partition_len;
> > 
> > If sbi->s_partition points to Metadata partition then reported number
> > of blocks seems to be incorrect. Similar like in udf_count_free().
> 
> Oh, right. This needs similar treatment like udf_count_free(). I'll fix it.
> Thanks for spotting.

Ok.

> > 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.

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