On Fri, Jan 21, 2005 at 03:29:16PM -0500, Brian Cuttler wrote:
> I think Jon LaBadie hit it

Cool.  I was speaking in ignorance of what the data looked like.

> There is a word that I like to use for this type of design. "Hidious"

Yup, that's a technical term :-)

> So a one block file would
> have a min size of 5 rather than 3 blocks.

Well, yes and no.  It does indeed consume 5 rather than 3 disk
blocks, and that shows up in "du" and "df" output and in how
quickly the partition fills up -- but a program that open()s and
read()s the file will still see exactly the same number of bytes,
no matter what the cluster size, or indeed the hardware sector
size [1].  That's why I said that tar wouldn't notice the
difference.

Dump doesn't go through the file system, but straight to the
disk, so theoretically, it could back up the unused bytes at the
end of a file's final cluster.  But there's no reason to do so,
and I'd hope that dump wouldn't be that dumb.

[1] This was one of UNIX's many innovations over then-current
    mainframe O/S's, which saw a file as a sequence of blocks,
    not of bytes as UNIX does.
    
    UNIX tried to do the same thing with tapes -- to abstract the
    concept of "file" away from its hardware implementation --
    but as I recently described in another thread, that
    experiment failed, which is why we have to worry about buffer
    lengths and short reads and all that bs= with tapes, but not
    with disk files.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        erics AT telepres DOT com
|  |  /
The animal that coils in a circle is the serpent; that's why so
many cults and myths of the serpent exist, because it's hard to
represent the return of the sun by the coiling of a hippopotamus.
        - Umberto Eco, "Foucault's Pendulum"