zfs discuss - Apr 2007 - quickly move files in different zfs in same zpool

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?
 
 
This message posted from opensolaris.org

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?

--T
>
>
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On April 12, 2007 7:10:34 PM -0300 Toby Thain <toby at smartgames.ca>
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

comment below...

Frank Cusack wrote:
> On April 12, 2007 7:10:34 PM -0300 Toby Thain <toby at smartgames.ca>
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

On 12-Apr-07, at 7:42 PM, Frank Cusack wrote:
> On April 12, 2007 7:10:34 PM -0300 Toby Thain <toby at smartgames.ca>
> 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. ...
>
> 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.
Which is just the long way of putting it. The OP seems to have found  
a way to use a new feature to make things -worse- for his particular  
application. Not the first time in history that''s happened,
I''m sure :-)

--T
>
> 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. ...
>
> -frank

zfs-discuss-bounces at opensolaris.org wrote on 04/12/2007 06:28:16 PM:
>
> On 12-Apr-07, at 7:42 PM, Frank Cusack wrote:
>
> > On April 12, 2007 7:10:34 PM -0300 Toby Thain <toby at
smartgames.ca>
> > 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. ...
> >
> > 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.
>
> Which is just the long way of putting it. The OP seems to have found
> a way to use a new feature to make things -worse- for his particular
> application. Not the first time in history that''s happened,
I''m sure :-)
>
File Systems in ZFS may be cheap (as far as zfs overhead) -- but they are
not "free". =)

Post it and forgot it :-)
And sincere thanks for so many replies of "This is not right" - which
is a standard sysadmin answer - which is probably the same answer I would give
out to others as well.
Actually I was inviting some answers like "how this can be done" or
"this can be done but the cost is too high so let''s not do
it"
No I don''t think different zfs''s in the same pool are the same
as different UFS''es on the same disk. The latter is physically
separated by partitions and while the data in the same pool are mingled together
so it *should* be much easier to move links around within the same pool.
 
 
This message posted from opensolaris.org