>Well, I don't know about his particular case, but many QFS clients
>have found the separation of da ta and metadata to be invaluable. The
>primary reason is that it avoids disk seeks. We have QFS cust omers who
>are running at over 90% of theoretical bandwidth on a medium-sized set
>of FibreChannel co ntrollers and need to maintain that streaming rate.
>Taking a seek to update the on-disk inodes once
>a minute or so slowed down transfers enough that QFS was invented.
;-)
That does not answer th equestion I asked; since ZFS is a copy-on-write
filesystem, there's no fixed inode location and streaming writes should
always be possible.
So, in theory ZFS can do this and mix metadata and data. That's why
I asked for any preactival input into this matter.
There are, I think, four different outcomes possible of such an
experiment and subsequent analysis:
ZFS does just fine, thank you
ZFS doesn't measure up but can be fixed without splitting meta data.
ZFS doesn't measure up and can only be fixed by allowing a logical
split
ZFS doesn't measure up and cannot be fixed
My money is on #2.
>ZFS will be a great file system for transactional work (small
>reads/writes) and its data integrity
>should be unmatched. But for large streaming, it's hard to beat QFS.
>(And it will take some clever ness to figure out a multi-host ZFS.)
I think ZFS should do fine in streaming mode also, though there are
currently some shortcomings, such as the mentioned 128K I/O size.
Casper
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
