From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Subject: XFS & LVM: unexpected cp when issuing mv
Date: Sun, 29 Nov 2009 14:52:16 +0100 [thread overview]
Message-ID: <200911291452.20646@zmi.at> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2619 bytes --]
I have an unexpected behaviour and I hope someone can explain me the
reasons:
This is an openSUSE 11.2 virtual machine within XENserver. XENserver can
only create 2TB disks, but I needed more. So I create 2x 2TB disks for
that VM. These disks have no partitions, but are straight LVM:
# pvscan
PV /dev/xvdb VG sharestore lvm2 [1,95 TB / 0 free]
PV /dev/xvdc VG sharestore lvm2 [1,95 TB / 0 free]
Total: 2 [3,91 TB] / in use: 2 [3,91 TB] / in no VG: 0 [0 ]
I created one VG, and then one LV:
# vgscan
Reading all physical volumes. This may take a while...
Found volume group "sharestore" using metadata type lvm2
# lvscan
ACTIVE '/dev/sharestore/public' [3,91 TB] inherit
On that LV, I created an XFS filesystem, mounted from /etc/fstab:
/dev/sharestore/public /disks/sharestore xfs
noatime,nodiratime,logbufs=8,logbsize=256k,attr2,nobarrier,largeio,swalloc,inode64,prjquota
Now when I move from one dir to another, example
mv /disks/sharestore/upload/* /disks/sharestore/download/
within some dirs it's a simple mv where only metadata is moved, but with
some dirs it's a physical cp+rm of the files. You can easily see that by
the speed of the mv, plus with iostat:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-
sz avgqu-sz await svctm %util
xvdb 0,00 0,00 0,00 647,31 0,00 28424,75
87,82 18,46 29,71 0,24 15,65
xvdc 0,00 0,40 631,14 2,40 26928,54 76,65
85,25 5,56 8,69 1,56 98,84
Until now I believed that a mv within one filesystem is always just a
metadata mv. But it seems I found a case now where even within the same
filesystem a physical cp+rm is done. Can someone explain me
1) why this happens
2) how I can prevent this?
We have files >5G there, often 20G or more, so a mv should just be a
metadata mv, everything else is inacceptable.
Could it be the way I created the VG + LV, that there's a cp instead mv?
How could I create all that to get a normal behaviour?
Maybe like this?:
1) create VG only on one disk
2) create LV on that disk
3) create XFS
4) extend VG to 2nd disk
5) extend LV to 2nd disk
6) xfs_growfs to 2nd disk
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660 / 415 65 31 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2009-11-29 13:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-29 13:52 Michael Monnerie [this message]
2009-11-29 14:41 ` XFS & LVM: unexpected cp when issuing mv Asdo
2009-11-30 13:32 ` Michael Monnerie
2009-11-29 23:27 ` Dave Chinner
2009-11-30 13:42 ` Michael Monnerie
2009-11-30 14:21 ` Alex Elder
2009-11-30 15:30 ` Michael Monnerie
2009-12-01 0:19 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200911291452.20646@zmi.at \
--to=michael.monnerie@is.it-management.at \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.