On Sat, Nov 29, 2014 at 10:37 PM, Robert White <rwh...@pobox.com> wrote: > > One thing to keep in mind is that mv, when crossing any of these boundaries > degenerates to a copy-and-remove operation and _none_ of the source files > will be removed until _all_ of the files have been copied. If any of the > copy operations fail the removes will not take place at all. It would only > take a couple large NOCOW files to put you over a limit somewhere.
Hmm... So you're saying like because the copy routine that mv calls will see the nocow attribute (and it doesn't know it's being called as part of a move operation) and so do a full copy rather than reflink? Correct me if I'm wrong but it seems that mv should actually ignore the nocow attribute as far as moving it to a new location is concerned, no, because I'm moving, not copying? Of course it should retain the attribute of the original files *after* the move is done. Why should noCoW affect cp --reflink anyhow? I just created a 500 MiB file from /dev/urandom under a chattr +C-ed dir, and copied to another subvol using cp --reflink, and fi df still shows 500 MiB, not 1 GiB. > If you are consolidating sub-volumes (as per the original question) on a > "nearly full" drive you may want to do it all long-hand with a script moving > various chunks or something instead of just trying a move/copy of "cp > --reflinks /vol1/* /vol2/" (same for mv when you get that --reflinks > revision). As I said, there doesn't actually seem to be a --reflink command line option. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
