Can moving data to a subvolume not take as long as a fully copy?
I made a mistake and copied data in the root of a new btrfs filesystem. I created a subvolume, and used mv to put everything in there. Something like:
cd /mnt
btrfs subvolume create dir
mv * dir
Except it's been running for over a day now (ok, it's 5TB of data)
Looks like mv is really copying all the data as if it were an entirely different filesystem.
Is there not a way to short circuit this and only update the metadata?
Thanks,
Marc
Signature · 4 lines
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ Quoted 7 lines · Marc MERLIN
I made a mistake and copied data in the root of a new btrfs filesystem. I created a subvolume, and used mv to put everything in there. Something like:
cd /mnt
btrfs subvolume create dir
mv * dir
Quoted 6 lines
Except it's been running for over a day now (ok, it's 5TB of data)
Looks like mv is really copying all the data as if it were an entirely different filesystem.
Is there not a way to short circuit this and only update the metadata?
I guess the best way of doing this in this case is to teach mv to
do cp --reflink=always then unlink the origin.
Clearly that won't work over mount boundaries (where a copy of the
data is the best you're going to get), but that's not what you've got here.
Hugo.
Signature · 3 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- He's playing Schubert. I think Schubert is losing. --- Quoted 13 lines · Hugo Mills
Quoted 12 lines · Marc MERLIN
I made a mistake and copied data in the root of a new btrfs filesystem. I created a subvolume, and used mv to put everything in there. Something like:
cd /mnt
btrfs subvolume create dir
mv * dirExcept it's been running for over a day now (ok, it's 5TB of data)
Looks like mv is really copying all the data as if it were an entirely different filesystem.
Quoted 8 lines
Quoted 1 line
Is there not a way to short circuit this and only update the metadata?
I guess the best way of doing this in this case is to teach mv to
do cp --reflink=always then unlink the origin.Clearly that won't work over mount boundaries (where a copy of the
data is the best you're going to get), but that's not what you've got here.
Mmmh, this made me think:
It seems that I could have done cp --reflink without duplicating the data and running out of space.
Then, I could have deleted the originals?
Is that correct?
Marc
Signature · 4 lines
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ Quoted 23 lines · Marc MERLIN
Quoted 13 lines · Hugo Mills
Quoted 12 lines · Marc MERLIN
I made a mistake and copied data in the root of a new btrfs filesystem. I created a subvolume, and used mv to put everything in there. Something like:
cd /mnt
btrfs subvolume create dir
mv * dirExcept it's been running for over a day now (ok, it's 5TB of data)
Looks like mv is really copying all the data as if it were an entirely different filesystem.
Quoted 8 lines
Quoted 1 line
Is there not a way to short circuit this and only update the metadata?
I guess the best way of doing this in this case is to teach mv to
do cp --reflink=always then unlink the origin.Clearly that won't work over mount boundaries (where a copy of the
data is the best you're going to get), but that's not what you've got here.
Quoted 6 lines
Mmmh, this made me think:
It seems that I could have done cp --reflink without duplicating the data and running out of space.
Then, I could have deleted the originals?Is that correct?
Yup, exactly what I just said above. :)
Hugo.
Signature · 4 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Your problem is that you've got too much taste to be ---
a web developer. Quoted 7 lines · Marc MERLIN
I made a mistake and copied data in the root of a new btrfs filesystem. I created a subvolume, and used mv to put everything in there. Something like:
cd /mnt
btrfs subvolume create dir
mv * dir
Quoted 6 lines
Except it's been running for over a day now (ok, it's 5TB of data)
Looks like mv is really copying all the data as if it were an entirely different filesystem.
Is there not a way to short circuit this and only update the metadata?
Why not make a snapshot of the root volume, and then delete the files you want to move from the original root, and delete the rest of root from the snapshot?
David
Quoted 3 lines · David Brown
Why not make a snapshot of the root volume, and then delete the files you want to move from the original root, and delete the rest of root from the snapshot?
Are a snapshot of the root volume and a subvolume effectively the same thing as far as btrfs sees them?
Once I have that snapshot which I'll treat as a subvolume, can I then snapshot that snapshot/subvolume further?
If so, that's definitely a good way of doing this for next time.
Thanks,
Marc
Signature · 4 lines
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ Quoted 10 lines · Marc MERLIN
Quoted 3 lines · David Brown
Why not make a snapshot of the root volume, and then delete the files you want to move from the original root, and delete the rest of root from the snapshot?
Are a snapshot of the root volume and a subvolume effectively the same thing as far as btrfs sees them?
Once I have that snapshot which I'll treat as a subvolume, can I then snapshot that snapshot/subvolume further?
Yes, the product of the btrfs snapshot command is a subvolume.