🚀 go-pugleaf

In <f2Dl02hm01UD01@JUTS.ccc.amdahl.com>, ked01@ccc.amdahl.com (Kim DeVaughn) writes:
>In article <6321@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
>> In article <d8zg02JJ01bI01@JUTS.ccc.amdahl.com> ked01@JUTS.ccc.amdahl.com (Kim DeVaughn) writes:
>> > While I understand that other such "oddities" may well arise in the future,
>> > what bothers me is not being able to ask the filesystem for the *true* info
>> > in a supported way.
>> 
>> *which* filesystem?
>
>Whichever filesystem is being addressed at the time.
>
>There *is* a field in the FIB called fib_NumBlocks.  What I would like is for
>that field to accurately reflect the actual number of blocks allocated (or
>some algorithmic variation thereof) by a file, at the time it is interrogated.
>
>That, and that a filesystem *document* what that field "means" in its own
>context.

This whole discussion has been a problem for me. I am trying to figure out
under what conditions a file system might not know how many blocks (minimum
storage units) a given length of data will take up.

I can see having some problems with reporting on a file system that supports a
variable block length, such as might be found on large IBM disks, where 'block'
has no meaning, and data is stored in 'records' with a count being part of the
record, but I think there is a way around even that.

I do think a file system should have the ability to return:

  1. the number of blocks left on a device, if appropriate.
  2. the number of blocks that will be used, if appropriate, given
     the length of a file's data.

The 'if appropriate' proviso would allow a file system to return a value to the
caller that in effect says 'I have no idea, mate, I just write it out and see
if it fits.'. A value of -1 would suffice. All file systems able to determine
the number of blocks required, should be able to tell the caller what the
requirements are.

-larry

--
Sex is better than logic, but I can't prove it.
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+