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@xxxxxxxxx
