zfs discuss - Apr 2010 - Data movement across filesystems within a pool

I would have thought that the file movement from one FS to another within the
same pool would be almost instantaneous. Why does it take to platter for such a
movement?

# time cp /tmp/blockfile /pcshare/1gb-tempfile
real    0m5.758s

# time mv /pcshare/1gb-tempfile .
real    0m4.501s

Both FSs are with compression=off. /tmp is RAM.

-devsk
-- 
This message posted from opensolaris.org

This is really painful. My source was a backup of my folders which I wanted as
filesystems in the RAIDZ setup. So, I copied the source to the new pool and
wanted to be able to move those folders to different filesystems within the
RAIDZ. But its turning out to be a brand new copy and since its a copy from same
devices, its slower than the original copy which was from a different pool.

10hours to move that data and probably another 20hours now to move data within
RAIDZ....sigh!
-- 
This message posted from opensolaris.org

Is there anything anybody has to advise? Will I be better of copying each folder
into its own FS from source pool? How about removal of the stuff that''s
now in this FS? How long will the removal of 770GB data containing 6millions
files take?

Cost1: copy folders into respective FS + remove already copied folders
Cost2: Move within the RAIDZ from folders of one FS to respective FS.

Which cost is theoretically more? I have just begun the move for one folder, so
I can probably stop and pick the other approach if someone gives me a good
reason for one vs. the other.
-- 
This message posted from opensolaris.org

Search the archives.  This dead horse gets beaten about every 6-9 months or so.
 -- richard

On Apr 24, 2010, at 7:37 AM, devsk wrote:
> Is there anything anybody has to advise? Will I be better of copying each
folder into its own FS from source pool? How about removal of the stuff
that''s now in this FS? How long will the removal of 770GB data
containing 6millions files take?
> 
> Cost1: copy folders into respective FS + remove already copied folders
> Cost2: Move within the RAIDZ from folders of one FS to respective FS.
> 
> Which cost is theoretically more? I have just begun the move for one
folder, so I can probably stop and pick the other approach if someone gives me a
good reason for one vs. the other.
> -- 
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
ZFS storage and performance consulting at http://www.RichardElling.com
ZFS training on deduplication, NexentaStor, and NAS performance
Las Vegas, April 29-30, 2010 http://nexenta-vegas.eventbrite.com

On Sat, 24 Apr 2010, devsk wrote:
> This is really painful. My source was a backup of my folders which I 
> wanted as filesystems in the RAIDZ setup. So, I copied the source to 
> the new pool and wanted to be able to move those folders to 
> different filesystems within the RAIDZ. But its turning out to be a 
> brand new copy and since its a copy from same devices, its slower 
> than the original copy which was from a different pool.
As Richard says this is a "dead horse".  While each filesystem obtains
its storage from the pool, they are still independent filesystems.

If you have the space for double the data, then I recommend creating 
the destination directory and then using this in the source directory

   find . -depth -print | cpio -pdum /destdir

Using something like ''mv'' would be dreadfully (even) slower.

Thankfully, zfs is pretty quick at recursively removing files.

Bob
--
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Could this be a future enhancement for ZFS? Like provide ''zfs move
fs1/<path1> fs2/<path2>'', which will do the needful without
really copying anything?
-- 
This message posted from opensolaris.org