This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: An importanta patch for glibc 2.1.1
- To: schwab@issan.informatik.uni-dortmund.de (Andreas Schwab)
- Subject: Re: An importanta patch for glibc 2.1.1
- From: hjl@lucon.org (H.J. Lu)
- Date: Fri, 9 Apr 1999 07:08:20 -0700 (PDT)
- Cc: libc-hacker@cygnus.com, gafton@redhat.com
>
> hjl@varesearch.com (H.J. Lu) writes:
>
> |> >
> |> > hjl@varesearch.com (H.J. Lu) writes:
> |> >
> |> > |> We need this patch for glibc 2.1.1.
> |> >
> |> > IMHO this patch is more appriopriate. According to SunOS4 the f_bsize
> |> ^^^^^^^
> |>
> |> Can we drop SunOS4 now?
>
> No, because Linux is still at bit similar: it also has only struct statfs
> and no struct statvfs.
>
> |> > member of struct statfs is the "fundamental file system block size" which
> |> > corresponds directly to f_frsize from statvfs. Any comments?
> |> >
> |>
> |> It is not what Solaris 7/SunOS5 says. It has:
> |>
> |> u_long f_bsize; /* preferred file system block size */
> |> u_long f_frsize; /* fundamental filesystem block
> |> (size if supported) */
>
> Exactly. struct statfs does not have f_frsize, and thus IMHO f_bsize
> plays exactly the same r\^ole in statfs as f_frsize does in statvfs.
> Names don't count, only meaning matters.
It doesn't matter. If we have f_frsize, "df" will use it with
f_blocks. Also people may use f_bsize for I/O. We have to make
both happy.
H.J.