''mv'' command took very long time to copy a large file from one ZFS directory to another. The directories share the same pool and file system. I had a 385 MB file in one directory and wanted to move that to a different directory. It took long time to move. Any particular reasons? There is no raid involved. -Pavan This message posted from opensolaris.org
Some details on what a long time is might be of help to us... Also - Some details on what type of hardware you are using... There are a number of known issues, as well as a number of known physical limitations that might get in your way. (eg: using multiple slices of the same disk in the same pool... ;) Perhaps if you could include as much detail as possible, we might be able to help a little more... Don''t forget to include what your expectations were for the time of the copy (ans the basis of those expectations!), versus reality... Some vmstat output, iostat -x output would also be helpful... Cheers, Nathan. On Mon, 2006-10-30 at 14:50, Pavan Reddy wrote:> ''mv'' command took very long time to copy a large file from one ZFS directory to another. The directories share the same pool and file system. I had a 385 MB file in one directory and wanted to move that to a different directory. It took long time to move. Any particular reasons? There is no raid involved. > > -Pavan > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss--
Hi, How much time is a "long time"? Second, had a snapshot been taken after the file was created? Are the src and dst directories in the same slice? What other work was being done at the time of the move? Were their numerous files in the src or dst directories? How much phys mem is in your system? Does a equivelent move take a drasticly shorter amount of time if done right after a reboot? Mitchell Erblich -------------- Pavan Reddy wrote:> > ''mv'' command took very long time to copy a large file from one ZFS directory to another. The directories share the same pool and file system. I had a 385 MB file in one directory and wanted to move that to a different directory. It took long time to move. Any particular reasons? There is no raid involved. > > -Pavan > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
This is the time it took to move the file:
The machine is a Intel P4 - 512MB RAM.
bash-3.00# time mv ../share/pav.tar .
real 1m26.334s
user 0m0.003s
sys 0m7.397s
bash-3.00# ls -l pav.tar
-rw-r--r-- 1 root root 516628480 Oct 29 19:30 pav.tar
A similar move on my Mac OS X took this much time:
pavan-mettus-computer:~/public pavan$ time mv pav.tar.gz ./Burn\ Folder.fpbf/
real 0m0.006s
user 0m0.001s
sys 0m0.004s
pavan-mettus-computer:~/public/Burn Folder.fpbf pavan$ ls -l pav.tar.gz
-rw-r--r-- 1 pavan pavan 347758518 Oct 29 19:09 pav.tar.gz
NOTE: The file size here is 347 MB where as the previous one was 516MB. But
still the time taken is huge when compared.
Its an X86 machine running Nevada build 51. More info about the disk and pool:
bash-3.00# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
mypool 29.2G 789M 28.5G 2% ONLINE -
bash-3.00# zfs list
NAME USED AVAIL REFER MOUNTPOINT
mypool 789M 28.0G 24.5K /mypool
mypool/nas 789M 28.0G 78.8M /export/home
mypool/nas/pavan 710M 28.0G 710M /export/home/pavan
mypool/nas/rajeev 24.5K 28.0G 24.5K /export/home/rajeev
mypool/nas/share 24.5K 28.0G 24.5K /export/home/share
It took lots of time when I moved the file from /export/home/pavan/ to
/export/home/share directory.
I was not doing any other operation other than the move command.
There are no files in that directories other than this one.
It has a 512MB Physical memory. The Mac machine has 1Gig RAM.
No snapshots are taken.
iostat and vmstat info:
bash-3.00# iostat -x
extended device statistics
device r/s w/s kr/s kw/s wait actv svc_t %w %b
cmdk0 3.1 3.0 237.9 132.8 0.6 0.1 112.6 2 3
fd0 0.0 0.0 0.0 0.0 0.0 0.0 3152.2 0 0
sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0
sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0
bash-3.00# vmstat
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr cd f0 s0 s1 in sy cs us sy id
0 0 0 2083196 111668 5 25 13 3 13 0 44 6 0 -1 -0 296 276 231 1 2 97
-Pavan
This message posted from opensolaris.org
Pavan Reddy wrote:> This is the time it took to move the file: > > The machine is a Intel P4 - 512MB RAM. > > bash-3.00# time mv ../share/pav.tar . > > real 1m26.334s > user 0m0.003s > sys 0m7.397s > > > bash-3.00# ls -l pav.tar > -rw-r--r-- 1 root root 516628480 Oct 29 19:30 pav.tar > > > A similar move on my Mac OS X took this much time: > > > pavan-mettus-computer:~/public pavan$ time mv pav.tar.gz ./Burn\ Folder.fpbf/ > > real 0m0.006s > user 0m0.001s > sys 0m0.004s > > pavan-mettus-computer:~/public/Burn Folder.fpbf pavan$ ls -l pav.tar.gz > -rw-r--r-- 1 pavan pavan 347758518 Oct 29 19:09 pav.tar.gz > > NOTE: The file size here is 347 MB where as the previous one was 516MB. But still the time taken is huge when compared. > > Its an X86 machine running Nevada build 51. More info about the disk and pool: > bash-3.00# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > mypool 29.2G 789M 28.5G 2% ONLINE - > bash-3.00# zfs list > NAME USED AVAIL REFER MOUNTPOINT > mypool 789M 28.0G 24.5K /mypool > mypool/nas 789M 28.0G 78.8M /export/home > mypool/nas/pavan 710M 28.0G 710M /export/home/pavan > mypool/nas/rajeev 24.5K 28.0G 24.5K /export/home/rajeev > mypool/nas/share 24.5K 28.0G 24.5K /export/home/share > > It took lots of time when I moved the file from /export/home/pavan/ to /export/home/share directory.You''re moving that file from one filesystem to another, so it will have to copy all the data of the file in addition to just a few metadata blocks. If you mv it within the same filesystem it will be quick (as in your OSX example). eric> > I was not doing any other operation other than the move command. > > There are no files in that directories other than this one. > > It has a 512MB Physical memory. The Mac machine has 1Gig RAM. > > No snapshots are taken. > > iostat and vmstat info: > bash-3.00# iostat -x > extended device statistics > device r/s w/s kr/s kw/s wait actv svc_t %w %b > cmdk0 3.1 3.0 237.9 132.8 0.6 0.1 112.6 2 3 > fd0 0.0 0.0 0.0 0.0 0.0 0.0 3152.2 0 0 > sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 > sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 > bash-3.00# vmstat > kthr memory page disk faults cpu > r b w swap free re mf pi po fr de sr cd f0 s0 s1 in sy cs us sy id > 0 0 0 2083196 111668 5 25 13 3 13 0 44 6 0 -1 -0 296 276 231 1 2 97 > > > -Pavan > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
This is the same problem described in 6343653 : want to quickly "copy" a file from a snapshot. On 10/30/06, eric kustarz <eric.kustarz at sun.com> wrote:> Pavan Reddy wrote: > > This is the time it took to move the file: > > > > The machine is a Intel P4 - 512MB RAM. > > > > bash-3.00# time mv ../share/pav.tar . > > > > real 1m26.334s > > user 0m0.003s > > sys 0m7.397s > > > > > > bash-3.00# ls -l pav.tar > > -rw-r--r-- 1 root root 516628480 Oct 29 19:30 pav.tar > > > > > > A similar move on my Mac OS X took this much time: > > > > > > pavan-mettus-computer:~/public pavan$ time mv pav.tar.gz ./Burn\ Folder.fpbf/ > > > > real 0m0.006s > > user 0m0.001s > > sys 0m0.004s > > > > pavan-mettus-computer:~/public/Burn Folder.fpbf pavan$ ls -l pav.tar.gz > > -rw-r--r-- 1 pavan pavan 347758518 Oct 29 19:09 pav.tar.gz > > > > NOTE: The file size here is 347 MB where as the previous one was 516MB. But still the time taken is huge when compared. > > > > Its an X86 machine running Nevada build 51. More info about the disk and pool: > > bash-3.00# zpool list > > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > > mypool 29.2G 789M 28.5G 2% ONLINE - > > bash-3.00# zfs list > > NAME USED AVAIL REFER MOUNTPOINT > > mypool 789M 28.0G 24.5K /mypool > > mypool/nas 789M 28.0G 78.8M /export/home > > mypool/nas/pavan 710M 28.0G 710M /export/home/pavan > > mypool/nas/rajeev 24.5K 28.0G 24.5K /export/home/rajeev > > mypool/nas/share 24.5K 28.0G 24.5K /export/home/share > > > > It took lots of time when I moved the file from /export/home/pavan/ to /export/home/share directory. > > You''re moving that file from one filesystem to another, so it will have > to copy all the data of the file in addition to just a few metadata > blocks. If you mv it within the same filesystem it will be quick (as in > your OSX example). > > eric > > > > > I was not doing any other operation other than the move command. > > > > There are no files in that directories other than this one. > > > > It has a 512MB Physical memory. The Mac machine has 1Gig RAM. > > > > No snapshots are taken. > > > > iostat and vmstat info: > > bash-3.00# iostat -x > > extended device statistics > > device r/s w/s kr/s kw/s wait actv svc_t %w %b > > cmdk0 3.1 3.0 237.9 132.8 0.6 0.1 112.6 2 3 > > fd0 0.0 0.0 0.0 0.0 0.0 0.0 3152.2 0 0 > > sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 > > sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 > > bash-3.00# vmstat > > kthr memory page disk faults cpu > > r b w swap free re mf pi po fr de sr cd f0 s0 s1 in sy cs us sy id > > 0 0 0 2083196 111668 5 25 13 3 13 0 44 6 0 -1 -0 296 276 231 1 2 97 > > > > > > -Pavan > > > > > > This message posted from opensolaris.org > > _______________________________________________ > > zfs-discuss mailing list > > zfs-discuss at opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-- Regards, Jeremy
Jeremy Teo wrote:> This is the same problem described in > 6343653 : want to quickly "copy" a file from a snapshot.Actually it''s a somewhat different problem. "Copying" a file from a snapshot is a lot simpler than "copying" a file from a different filesystem. With snapshots, things are a lot more constrained, and we already have the infrastructure for a filesystem referencing the same blocks as its snapshots. --matt