In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes:
>Poul-Henning Kamp wrote:
>>
>> I was just looking at that piece of code, and I couldn't entirely
>> make out what it was even trying to do. Can somebody more
>> linuxolator savy explain what the function linux_ustat() should
>> produce.
>
>The following comment explains what linux_ustat should do:
>
> /*
> * lu.f_fname and lu.f_fpack are not used. They are always zeroed.
> * lu.f_tinode and lu.f_tfree are set from the device's super block.
> */
>
>linux_ustat fills in a structure with the above mention fields. The
>meaning of f_tinode and f_tfree are explained by the following two
>statements:
>
> lu.f_tfree = stat->f_bfree;
> lu.f_tinode = stat->f_ffree;
>
>In short: given the (u)dev_t, get the FS statistics and return the
>number of free blocks and inodes of the FS on that device.
But the udev_t is a (32bit truncated to) 16bit one, right ?
In that case it will usually not work:
crw-r----- 1 root operator 116, 0x00010002 1 Jan 1970 /dev/ad0
crw-r----- 1 root operator 116, 0x00020000 1 Jan 1970 /dev/ad0s1a
crw-r----- 1 root operator 116, 0x00020001 1 Jan 1970 /dev/ad0s1b
crw-r----- 1 root operator 116, 0x00020004 1 Jan 1970 /dev/ad0s1e
crw-r----- 1 root operator 116, 0x00020005 1 Jan 1970 /dev/ad0s1f
crw-r----- 1 root operator 116, 0x00030002 1 Jan 1970 /dev/ad0s2c
crw-r----- 1 root operator 116, 0x00040000 1 Jan 1970 /dev/ad0s3a
crw-r----- 1 root operator 116, 0x00040003 1 Jan 1970 /dev/ad0s3d
Considering the fact that we were likely to return statistics for the
wrong filesystem with the old code, and most likely cannot return
the right statistics anyway, I think we should just return zero
for those values (or some other more sensible values)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message