comment below...
Frank Cusack wrote:
On April 12, 2007 7:10:34 PM -0300 Toby Thain <[EMAIL PROTECTED]> wrote:
On 12-Apr-07, at 3:40 PM, Sean Liu wrote:
In good'ol days if you are moving file/files in the same UFS, it's
a snap as the moving is only a change in dir/inode level.
Since zfs encourages creating more filesystems instead of dirs,
moving can be an issue - data must be moved around instead of being
pointed to, so it takes a long time if the size is big, even though
the data is still in the same zpool.
Any workaround for this?
Think hard about usage patterns when you lay out your filesystems?
Nice snappy answer :-), but in a lot of cases, you might not know what
the usage will be.
In any case, there has been talk about 'zfs split' or some such which
would fork off a filesystem at some directory. I think the consensus
was that this would be hard. Someone who actually knows can probably
chime in here.
Now, back to the question, while zfs ENCOURAGES creating more filesystems,
you don't have to do that. In fact in some cases it's a distinct
disadvantage. So I'd say a workaround would be to just not create
multiple filesystems! If you don't need them, don't do it. You need
to ask yourself, what is the REASON that you would have different
filesystems, and if you don't have any other than "well that's the zfs
way", then stick with fewer filesystems.
+100
I like to describe it as create a new file system when you need to
implement a different policy. Examples of policies include:
+ read-only or read-write
+ uncompressed or compressed (by compression algorithm)
+ frequent or infrequent snapshots
+ redundancy (copies=1,2,3)
+ unshared or shared (by share type)
+ mounted at boot or not
+ atime enabled
+ quota
+ special case being developed for easy LiveUpgrade (/, /opt, et.al)
I'm sure this list will grow, but hopefully you will get the idea.
-- richard
_______________________________________________
zfs-discuss mailing list
[EMAIL PROTECTED]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
