michael@stb.UUCP (Michael) (02/29/88)
What's going on here? I just checked several large files, and find that the number of blocks allocated to them (as reported by 'lc -s') does not agree with number of bytes/512. Instead anywhere from 3 to 12 extra blocks are allocated to the file. Is this an error in lc, or is the kernel trying (and failing) to do preallocation? If the latter, then A) Why isn't it documented B) Why isn't is configurable (or at least disableable) Michael -- : Michael Gersten <best> => uunet!ucla-an.ANES\ : ihnp4!hermix!ucla-an!remsit!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : "A hacker lives forever, but not so his free time"
uhclem@trsvax.UUCP (03/05/88)
<"I'll huff and I'll puff and I'll get promoted." - Old management saying>
B>michael at stb.UUCP writes:
B>What's going on here? I just checked several large files, and find that
B>the number of blocks allocated to them (as reported by 'lc -s') does
B>not agree with number of bytes/512. Instead anywhere from 3 to 12 extra
B>blocks are allocated to the file.
B>Is this an error in lc, or is the kernel trying (and failing) to do
B>preallocation? If the latter, then A) Why isn't it documented
B> B) Why isn't is configurable (or at least disableable)
I suspect you do not have the manual page on LC(C) or LS(C), or you did not
read all of it. In the 3.0.0 Development System XENIX Reference (C) section,
the sentence preceding the "Files" section of LC/LS(C) says:
"When the sizes of the files in a directory are listed, a total count of
blocks including indirect blocks is printed."
^^^^^^^^^^^^^^^^^^^^^^^^^
If your file is larger than 10 blocks, you are guaranteed at least one
indirect block. The bigger the file, the more indirect or indirect-indirect
blocks a file will have.
<This information is provided by an individual and is not nor should be
construed as being provided by Radio Shack or Tandy Corp. Radio
Shack/Tandy Corp has no obligation to support the information provided
in any way. Since it is almost, but not completely, unlike MS-DOS, it
likely isn't supported anyway, much less understood.>
"Thank you, Uh Clem."
Frank Durda IV
@ <trsvax!uhclem>
...decvax!microsoft!trsvax!uhclem
...convex!infoswx!hal6000!trsvax!uhclem