On 4/20/07, Tim Thomas <[EMAIL PROTECTED]> wrote:
My initial reaction is that the world has got by without file systems that can do this for a long time...so I don't see the absence of this as a big deal. On the other hand, it hard to argue against a feature that
I admit that this is "typically" not a big deal but as we move more data, it is not so much of whether a data corruption happens but when it will be serious enough. I do not have any statistics on this though.
improves data integrity, so I will not. Anyway, SAM-FS has been enhanced in this respect...in SAM-FS 4.6 you can enable the following... ... http://www.sun.com/products-n-solutions/hardware/docs/Software/Storage_Software/Sun_SAM-FS_and_Sun_SAM-QFS_Software/index.html This checksum model is different than ZFS and is more like the way a backup product verifies its backups.
I briefly went through the release notes. This feature provides checksumming still of 2nd hand data but definitely warrants a good look since it is going to be cheaper than using ZFS for the same job. ZFS will require redundancy at each archive copy. What interests me a lot is http://www.sun.com/products-n-solutions/hardware/docs/html/819-7938-10/index.html#69093 "New Recycling Tool for Archive Copy Retention". We wrote a mini-hack to prevent recycling of tape volumes that potentially still holds relevant backups.
> > We have considered the setup you proposed (samfs copy1 -> ZFS) but you > will run into problem with fs-cache. Being only a copy, ZFS probably > do not need much caching but will win the battle for memory due to the > way its cache is managed. Unless there is a visible memory shortfall, > ZFS will starve (sorry guys) samfs from memory it could use as cache. > Also, ZFS's data integrity feature is limited by the use of 2nd hand > data. > I don't know enough about how ZFS manages memory other than what I have seen on this alias (I just joined a couple of weeks ago) which seems to indicate it is a memory hog...as is VxFS so we are in good company. I am not against keeping data in memory so long as it has also been written to somewhere non-volatile as well so that data is not lost if the lights go out... and applications don't fight for memory to run. I recall stories from years ago where VxFS hogged so much memory on a Sun Cluster node that the Cluster services stalled and the cluster failed over!
ZFS implements ARC (Adaptive Replacement Cache) using kernel pages and has mechanism to release memory back to the system when memory is low. What I'm saying is that in the fight for memory, SAMFS will lose. I'm a huge fan of ZFS but in this case, it's not the primary file system so we should have some semantics to tell it say so.
I need to go read some white papers on this...but I assume that something like direct I/O (which UFS, VxFS and QFS all have) is in the plans for ZFS so we don't end up double buffering data for apps like databases ? - that is just ugly.
Not sure about the whitepapers but I'm sure the ZFS developers can answer that :P. -- Just me, Wire ... Blog: <prstat.blogspot.com> _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
