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@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
