On Dec 31, 2009, at 1:43 AM, Andras Spitzer wrote:
Let me sum up my thoughts in this topic.
To Richard [relling] : I agree with you this topic is even more
confusing if we are not careful enough to specify exactly what we
are talking about. Thin provision can be done on multiple layers,
and though you said you like it to be closer to the app than closer
to the dumb disks (if you were referring to SAN), my opinion is that
each and every scenario has it's own pros/cons. I learned long time
ago not to declare a technology good/bad, there are technologies
which are used properly (usually declared as good tech) and others
which are not (usually declared as bad).
I hear you. But you are trapped thinking about 20th century designs
and ZFS is a
21st century design. More below...
Let me clarify my case, and why I mentioned thin devices on SAN
specifically. Many people replied with the thin device support of
ZFS (which is called sparse volumes if I'm correct), but what I was
talking about is something else. It's thin device "awareness" on the
SAN.
In this case you configure your LUN in the SAN as thin device, a
virtual LUN(s) which is backed by a pool of physical disks in the
SAN. From the OS it's transparent, so it is from the Volume Manager/
Filesystem point of view.
That is the basic definition of my scenarion with thin devices on
SAN. High-end SAN frames like HDS USP-V (feature called "Hitachi
Dynamic Provisioning"), EMC Symmetrix V-Max (feature called "Virtual
provisioning") supports this (and I'm sure many others as well). As
you discovered the LUN in the OS, you start to use it, like put
under Volume Manager, create filesystem, copy files, but the SAN
only allocates physical blocks (more precisely group of blocks
called extents) as you write them, which means you'll use only as
much (or a bit more rounded to the next extent) on the physical disk
as you use in reality.
From this standpoint we can define two terms, thin-friendly and
thin-hostile environments. Thin-friendly would be any environment
where OS/VM/FS doesn't write to blocks it doesn't really use (for
example during initialization it doesn't fills up the LUN with a
pattern or 0s).
That's why Veritas' SmartMove is a nice feature, as when you move
from fat to thin devices (from the OS both LUNs look exactly the
same), it will copy the blocks only which are used by the VxFS files.
ZFS does this by design. There is no way in ZFS to not do this.
I suppose it could be touted as a "feature" :-) Maybe we should brand
ZFS as "THINbyDESIGN(TM)" Or perhaps we can rebrand
SMARTMOVE(TM) as TRYINGTOCATCHUPWITHZFS(TM) :-)
That is still the basics of having thin devices on SAN, and hope to
have a thin-friendly environment. The next level of this is the
management of the thin devices and the physical pool where thin
devices allocates their extents from.
Even if you get migrated to thin device LUNs, your thin devices will
become fat again, even if you fill up your filesystem once, the thin
device on the SAN will remain fat, no space reclamation is happening
by default. The reason is pretty simple, the SAN storage has no
knowledge of the filesystem structure, as such it can't decide
whether a block should be released back to the pool, or it's really
not in use. 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.
I really would like you to read this Quick Note from Veritas about
this feature, it will explain way better the concept as I did : http://ftp.support.veritas.com/pub/support/products/Foundation_Suite/338546.pdf
Btw, in this concept VxVM can even detect (via ASL) whether a LUN is
thin device/thin device reclamation capable or not.
Correct. Since VxVM and VxFS are separate software, they have expanded
the interface between them.
Consider adding a mirror or replacing a drive.
Prior to SMARTMOVE, VxVM had no idea what part of the volume was data
and what was unused. So VxVM would silver the mirror by copying all of
the
blocks from one side to the other. Clearly this is uncool when your SAN
storage is virtualized.
With SMARTMOVE, VxFS has a method to tell VxVM that portions of the
volume are unused. Now when you silver the mirror, VxVM knows that
some bits are unused and it won't bother to copy them. This is a bona
fide good thing for virtualized SAN arrays.
ZFS was designed with the knowledge that the limited interface between
file systems and volume managers was a severe limitation that leads to
all sorts of complexity and angst. So a different design is needed. ZFS
has fully integrated RAID with the file system, so there is no need, by
design, to create a new interface between these layers. In other words,
the only way to silver a disk in ZFS is to silver the data. You can't
silver
unused space. There are other advantages as well. For example, in
ZFS silvers are done in time order, which has benefits for recovery
when devices are breaking all around you. Jeff describes this rather
nicely in his blog:
http://blogs.sun.com/bonwick/entry/smokin_mirrors
In short. ZFS doesn't need SMARTMOVE because it doesn't have the
antiquated view of storage management that last century's designs
had. Also, ZFS users who don't use snapshots could benefit from TRIM.
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)
I don't see that evolution. But I've always contended that storage
arrays are just specialized servers which speak a limited set of
protocols. After all, there is no such thing as "hardware RAID,"
all RAID is done in software. So my crystal ball says that such
limited server OSes will have a hard life ahead of them.
If you ask me the pool concept always works more efficient if 1# you
have more capacity in the pool 2# if you have more systems to share
the pool, that's why I see the thin device pool more rational in a
SAN frame.
Anyway, I'm sorry if you were already aware what I explained above,
I also hope I didn't offend anyone with my views,
I have a much simpler view of VxFS and VxVM. They are neither
open source nor free, but they are so last century :-)
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
