An importanta patch for glibc 2.1.1

[Andreas Schwab]

hjl@lucon.org (H.J. Lu) writes:

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

Only if nonzero.

|> Also people may use f_bsize for I/O. We have to make
|> both happy.

So my proposal will make both happy, won't it?  Except that i now favor
setting f_frsize to zero, since Linux does not support it.

Andreas.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org