On 31 dec 2009, at 10.43, Andras Spitzer wrote: > Then came Veritas with this brilliant idea of building a bridge between the > FS and the SAN frame (this became the Thin Reclamation API), so they can > communicate which blocks are not in use indeed.
This is exactly what TRIM is for, but could be implemented in a very light weight, general purpose way in all operating systems file systems and storage devices. Once things implement this, sparsing/thinning out disks will be a non issue. This will be the same simple mechanism and useful all the way from the laptop to the enterprise virtual server environment. I don't see any need for a big complicated system for this. > Honestly I have mixed feeling about ZFS. I feel that this is obviously the > future's VM/Filesystem, but then I realize in the same time the roles of the > individual parts in the big picture are getting mixed up. Am I the only one > with the impression that ZFS sooner or later will evolve to a SAN OS, and the > zfs, zpool commands will only become some lightweight interfaces to control > the SAN frame? :-) (like Solution Enabler for EMC) ZFS et al can today be a "SAN frame", that is what the OpenStorage product family is. (Not with all the bells and whistles of some of the other systems, but a lot cheaper (not ridiculously expensive, only very expensive (list price, which no one pays of course)).) Another possible interim solution to sparsing (thinning) out disks if you have dedup or compression in your storage thingy: write large files with for example zeros on the free space on the clients and remove them again, these blocks will dedup and/or compress nicely. /ragge s _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
