On Dec 30, 2009, at 2:24 PM, Ragnar Sundblad wrote:
On 30 dec 2009, at 22.45, Richard Elling wrote:
On Dec 30, 2009, at 12:25 PM, Andras Spitzer wrote:
Richard,
That's an interesting question, if it's worth it or not. I guess
the question is always who are the targets for ZFS (I assume
everyone, though in reality priorities has to set up as the
developer resources are limited). For a home office, no doubt thin
provisioning is not much of a use, for an enterprise company the
numbers might really make a difference if we look at the space
used vs space allocated.
There are some studies that thin provisioning can reduce physical
space used up to 30%, which is huge. (Even though I understands
studies are not real life and thin provisioning is not viable in
every environment)
Btw, I would like to discuss scenarios where though we have over-
subscribed pool in the SAN (meaning the overall allocated space to
the systems is more than the physical space in the pool) with
proper monitoring and proactive physical drive adds we won't let
any systems/applications attached to the SAN realize that we have
thin devices.
Actually that's why I believe configuring thin devices without
periodically reclaiming space is just a timebomb, though if you
have the option to periodically reclaim space, you can maintain
the pool in the SAN in a really efficient way. That's why I found
Veritas' Thin Reclamation API as a milestone in the thin device
field.
Anyway, only future can tell if thin provisioning will or won't be
a major feature in the storage world, though as I saw Veritas
already added this feature I was wondering if ZFS has it at least
on it's roadmap.
Thin provisioning is absolutely, positively a wonderful, good
thing! The question
is, how does the industry handle the multitude of thin provisioning
models, each
layered on top of another? For example, here at the ranch I use
VMWare and Xen,
which thinly provision virtual disks. I do this over iSCSI to a
server running ZFS
which thinly provisions the iSCSI target. If I had a virtual RAID
array, I would
probably use that, too. Personally, I think being thinner closer to
the application
wins over being thinner closer to dumb storage devices (disk drives).
I don't get it - why do we need anything more magic (or complicated)
than support for TRIM from the filesystems and the storage systems?
TRIM is just one part of the problem (or solution, depending on your
point
of view). The TRIM command is part of the T10 protocols that allows a
host to tell a block device that data in a set of blocks is no longer of
any value, and the block device can destroy the data without adverse
consequence.
In a world with copy-on-write and without snapshots, it is obvious that
there will be a lot of blocks running around that are no longer in use.
Snapshots (and their clones) changes that use case. So in a world of
snapshots, there will be fewer blocks which are not used. Remember,
the TRIM command is very important to OSes like Windows or OSX
which do not have file systems that are copy-on-write or have decent
snapshots. OTOH, ZFS does copy-on-write and lots of ZFS folks use
snapshots.
That said, adding TRIM support is not hard in ZFS. But it depends on
lower level drivers to pass the TRIM commands down the stack. These
ducks are lining up now.
I don't see why TRIM would be hard to implement for ZFS either,
except that you may want to keep data from a few txgs back just
for safety, which would probably call for some two-stage freeing
of data blocks (those free blocks that are to be TRIMmed, and
those that already are).
Once a block is freed in ZFS, it no longer needs it. So the "problem"
of TRIM in ZFS is not related to the recent txg commit history. The
issue is that traversing the free block list has to be protected by
locks, so that the file system does not allocate a block when it is
also TRIMming the block. Not so difficult, as long as the TRIM
occurs relatively quickly.
I think that any TRIM implementation should be an administration
command, like scrub. It probably doesn't make sense to have it
running all of the time. But on occasion, it might make sense.
My concern is that people will have an expectation that they can
use snapshots and TRIM -- the former reduces the effectiveness
of the latter. As the price of storing bytes continues to decrease,
will the cost of not TRIMming be a long term issue? I think not.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
