On Jan 1, 2010, at 11:04, Ragnar Sundblad wrote:
But that would only move the hardware specific and dependent flash
chip handling code into the file system code, wouldn't it? What
is won with that? As long as the flash chips have larger pages than
the file system blocks, someone will have to shuffle around blocks
to reclaim space, why not let the one thing that knows the hardware
and also is very close to the hardware do it?
And if this is good for SSDs, why isn't it as good for rotating rust?
Don't really see how things are either hardware specific or dependent.
COW is COW. Am I missing something? It's done by code somewhere in the
stack, if the FS knows about it, it can lay things out in sequential
writes. If we're talking about 512 KB blocks, ZFS in particular would
create four 128 KB txgs--and 128 KB is simply the currently #define'd
size, which can be changed in the future.
One thing you gain is perhaps not requiring to have as much of a
reserve. At most you have some hidden bad block re-mapping, similar to
rotating rust nowadays. If you're shuffling blocks around, you're
doing a read-modify-write, which if done in the file system, you could
use as a mechanism to defrag on-the-fly or to group many small files
together.
Not quite sure what you mean by your last question.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
