Re: Big files in ext2fs (but not i_osync)

Tue, 3 Mar 1998 23:03:24 +0100 (CET)

On Tue, 3 Mar 1998, Albert D. Cahalan wrote:

> > The capability for handling sparse files is quite powerful, and when
> > you are talking about databases or other aggregate file types it is a
> > very useful feature, especially for stuff you want to mmap().
> On traditional unix filesystems where holes work, blocks near the end
> of a file take longer to access because of triple-indirect blocks.
> Would you want a slow database?

i dont know how this is related to 'sparse files'.

> The "sparseness" of a sparse file is fragile accross network
> filesystems and archives. Eeew.

tar knows about holes, and it works wonderfully.

> Many databases operate on raw partitions. Clearly, sparse files
> can not be a database requirement.

'raw partitions', hm, who was the one talking about obsolete features?

> > A problem with it in its current configuration is the lack of a
> > punch() system call that can be used to hole out unused blocks, but to
> > say that sparse files are broken and obsolete is nothing but crap.
> It is hard to imagine glibc supporting something nonstandard
> like that. It isn't portable you know, like llseek()...

you are on the wrong track, zeroed out files are (holes) a very powerful
concept. It stems from the way mmap() works, any 'newly allocated memory'
is zeroed out. Thus support for 'zeroed out areas' in the filesystem is
pretty straightforward. As well as punch()/fclear(). Why dont you think
about it for a while.

-- mingo

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to