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
Robert Milkowski said the following :
Hello Tim,
Thursday, April 19, 2007, 10:32:53 AM, you wrote:
TT> Hi
TT> This is a bit off topic...but as Bill mentioned SAM-FS...my job at Sun
TT> is working in a group focused on ISV's in the archiving space (Symantec
TT> Enterprise Vault, Open Text LEA, CA Message Manager, FileNet, Mobius,
TT> AXS-One etc etc)...we see a strong interest from some of them in using
TT> SAM-FS because is solves the problem of backing up _archived _data. I
TT> just completed some interesting projects with Symantec using SAMBA +
TT> SAM-FS (Enterprise Vault is a Windows App).
TT> One thing we have considered is using SAM-FS & ZFS together on a
TT> server....the archived data is written into SAM-FS by the application
TT> which later copies it to ZFS (which is then a mid-tier disk archive)
TT> and tape (last tier). SAM-FS is being Open Sourced real soon (for people
TT> who care about that) also runs on x64 now.
TT> SAM-FS + ZFS + Thumper (Sun Fire x4500) + tape could be a nice back end
TT> for an archiving application.
Does SAM-FS work with ZFS right now? I thought that it works only with
QFS...?
--
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
