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.
If you do find it useful and do create multiple filesystems, then it's
the same as with UFS and you must somehow copy the data. With UFS,
even though the data is on the same physical disk, you can't just
move stuff across filesystems by updating some pointer. So think of
a zpool in zfs as a disk in UFS, and don't feel you're losing out
on something because you can't move stuff across filesystems in the
same zpool.
-frank
_______________________________________________
zfs-discuss mailing list
[EMAIL PROTECTED]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
