>>> Maybe, but it does not allow any form of sparse files!
>>
>> Sure it does, since you can always revert to traditional ext2
>> as soon as some broken software tries to make a sparse file.
>> If extents already exist, the remaining ones get filled in with
>> one-block references to block 0.
>>
>> A file with 1 block at a random location is never going to be
>> faster than a file with 1 block at the beginning, and it will
>> always be slower on traditional unix filesystems like ext2.
>> I think sparse files are a hack related to a.out binary format
>> and obsolete database libraries.
>
>
> <FLAME>
>
> Albert, you think any feature you don't personally use is a waste and
> obsolete! I'm sorry for the observation, but I can't shut up about
> this anymore...
>
> </FLAME>
I don't know how I deserve this. I didn't suggest _trying_ to
remove hole support, but if elimination makes something else work
better then the holes can go. Hole support is nice, not critical.
I wasn't the person wanting to eliminate various drivers.
I like supporting wasteful obsolete features when they don't get
in the way of anything else. The perfect example would be STREAMS.
It is junk, but I wish the patches were accepted. The program I'm
working on accepts really obsolete features that even the BSD crowd
disowns, such as "ps t" and "ps t?".
> 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?
The "sparseness" of a sparse file is fragile accross network
filesystems and archives. Eeew.
Many databases operate on raw partitions. Clearly, sparse files
can not be a database requirement.
> 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()...
(but the strange gcc extensions are OK -- go figure)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu