public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: xfs@oss.sgi.com
Subject: Re: XFS & LVM: unexpected cp when issuing mv
Date: Mon, 30 Nov 2009 10:27:16 +1100	[thread overview]
Message-ID: <20091129232716.GC30608@discord.disaster> (raw)
In-Reply-To: <200911291452.20646@zmi.at>

On Sun, Nov 29, 2009 at 02:52:16PM +0100, Michael Monnerie wrote:
> 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

You are using project quotas.

> 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

It happens if you move from one project directory heirarchy to
another - rename is not allowed across project quota boundaries as
the moved data has to be correctly attributed to the new project.
Hence it causes a mv to do a copy/unlink by returning a EXDEV error
to the rename.

> 2) how I can prevent this?

You can't if you are moving from one project to another. If you
move within the project heirarchy, then it will be a rename as per
normal.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2009-11-29 23:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-29 13:52 XFS & LVM: unexpected cp when issuing mv Michael Monnerie
2009-11-29 14:41 ` Asdo
2009-11-30 13:32   ` Michael Monnerie
2009-11-29 23:27 ` Dave Chinner [this message]
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=20091129232716.GC30608@discord.disaster \
    --to=david@fromorbit.com \
    --cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox