Hi Wee
I run a setup of SAM-FS for our main file server and we loved the
backup/restore parts that you described.
That is great to hear.
The main concerns I have with SAM fronting the entire conversation is
data integrity. Unlike ZFS, SAMFS does not do end to end checksumming.
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
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...
/If required, you can enable data verification for archive copies. This
feature checks
for data corruption on any data that is copied to secondary and/or
tertiary media.
The data verification process performs a read-after-write verification
test, and
records a confirmation of data validity in the metadata properties for
that file.
An ssum option is used to mark files and directories as needing to be
verified. Child
directories inherit the data verification properties of their parent.
The normal
checksum method is employed to verify copies written to tape or disk
archive.
Use the ssum -e command to set data verification for a file or
directory. This forces
the generation and use of checksums for archiving and staging, and
prevents the
release of the file until all archive copies have been created and their
checksums
verified. Only a superuser can set this attribute on a file or directory./
This is taken from the Sun StorageTek SAM Archive Configuration and
Administration Guide Version 4, Update 6 (SAM-FS 4.6 was released April
6th). You can get all the SAM-FS 4.6 docs from here...
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.
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!
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.
Rgds
Tim
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
