Hi Tim, I run a setup of SAM-FS for our main file server and we loved the backup/restore parts that you described.
The main concerns I have with SAM fronting the entire conversation is data integrity. Unlike ZFS, SAMFS does not do end to end checksumming. 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. -- Just me, Wire <http://prstat.blogspot.com> On 4/19/07, Tim Thomas <[EMAIL PROTECTED]> wrote:
Hi Robert no, SAM-FS does not work with ZFS, it is still tied to QFS i.e. the SAM piece cannot archive data straight out of a ZFS file system. I am a big fan of SAM-FS so forgive me if I expand a little on the topic... The way a solution like this would work is that you would build a SAM-FS file system on some of the disks and a ZFS file system on some others. Maybe SAM-FS would be on "fast" disks and ZFS on "slow" disks. Your application would write files into the SAM-FS file system. In my work this application would be an archiving application that has extracted data (e.g emails) out of a business application and now wants somewhere to put the archived data. SAM-FS can then make copies of the files (back them up) in to the ZFS file system and to tape (at the same or another time) up to a maximum of 4 copies...so from SAM-FS's perspective ZFS is being treated as a disk archive....SAM-FS does not care that it writing to a ZFS file system ..it just sees a directory that it can treat as a target to make backup copies of data into. ZFS is nice here because it can be used with JBODs and can do software RAID. SAM-FS (and it's little brother QFS which is the file system without the archiving), both do software RAID, but only RAID-0...so the underlying "disks" need to be h/ware RAID protected or logical volumes built with something like Solaris Volume Manager. So (you may ask) why would anyone want to do this ? Well...think of the SAM-FS file system as a cache...once it has backed up a file to a disk and/or tape archive it can be configured to "release" the file's data blocks and just leave a stub behind. The file is now viewed as off-line (Hey, this looks like HSM!) - There are a rich set of rules you can define around when this happens - the simplest is to do it when the file system passes a high %full watermark...in short..IT NEVER FILLS UP! So that is pretty cool...so here is the next really nice bit, the files are backed up continuously (once again. there are a rich set of rules around this)...no huge backup windows while millions of small files are backed up like a conventional backup product...SAM-FS will back them up throughout the day...also, NO INCREMENTAL BACKUPS required...we are working at a per file level here. If a file is written and never changes SAM-FS will make copies of it and then we are done..we never copy it again unless it changes...there is just one image of the file system. SAM-FS handles all the interaction with tape libraries etc...no extra s/ware required. So, what if you open a released file ? Once you read past the end of the stub SAM-FS stages the rest of the data back from archives....it is transparent...and it really is...if the file is having to come back from tape the long delays can cause application issues sometimes but files coming back from disk archives come back so fast that there are no problems. You can access SAM-FS via NFS and CIFS/SAMBA safely. NFS client need to support correct handling of the NFS EJUKEBOX error code...Solaris's does. Now, what if you loose a whole file system with millions of files in it. Recovering that from backups is no fun. part of managing SAM-FS is taking regular backups of the metadata...this is effectively a snapshot. If a file system is lost due to catastrophic h/ware failure then you can restore the meta into an empty SAM-FS file system (which can be smaller or larger than the original) in a few minutes and bingo, all the data is there again..with all the files off-line. SAM-FS management is all via the command line or via a really nice Web based UI. I won't pretend that it is as easy as ZFS to create a SAM-FS file system 'cause it aint'..but heck, it's fun once you get with it...and the GUI certainly makes life much easier. So..what is the "bad" stuff, other than no RAID-Z equivalent, well: you cannot grow a SAM-FS file system on-line..it needs to be unmounted first; No snapshots (other than the meta data based ones); you have to back up the meta data regularly as that is effectively the backup catalog which can be a drag but the procedures are well defined. There is other stuff that SAM-FS can do such as shared Global File system support in SAN's etc...but I have gone on enough!! Rgds Tim
... _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
