moving btrfs subvolumes to new disk

moving btrfs subvolumes to new disk

[Ryan Erato]

I'm having quite the time trying to move my current Gentoo install to
an SSD. I first attempted Clonezilla, but that failed while cloning
the btrfs partition. I then realized I could use btrfs send/receive.

The partition has 2 subvolumes ROOT and ROOT/home. ROOT snapshots and
sends without hitch, but /home consistently errors at the same point
(from -vv output on btrfs send). btrfs send returns -2, no such file
or directory, unexpected EOF in stream.

I've read on several sites there have been path bugs and have
attempted to mount the destination drive multiple ways (with and
without specifying ROOT subvol), have taken and saved the /home
snapshot in multiple locations, but all to no avail. Below is as much
information as I can think to give; admittedly I am a bit fresh to
this fs, but I know this can be done.

Thanks for any help!

# uname -a
Linux 4.1.12-gentoo #1 SMP Thu Nov 26 12:08:14 PST 2015 x86_64
Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz GenuineIntel GNU/Linux

# btrfs --version
btrfs-progs v4.0.1

# btrfs fi show
Label: 'Gentoo'  uuid: 6bb38bce-d824-4b9c-8b03-adad460c0f97
Total devices 1 FS bytes used 72.16GiB
devid    1 size 92.02GiB used 82.06GiB path /dev/sda6

# btrfs fi df /
Data, single: total=75.00GiB, used=70.77GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=3.50GiB, used=1.40GiB
GlobalReserve, single: total=480.00MiB, used=0.00B

# cat /etc/fstab
/dev/sda4 /boot vfat noauto,noatime 1 2
/dev/sda6 / btrfs defaults,noatime,compress=lzo,autodefrag,subvol=ROOT 0 0
/dev/sda5 none swap sw 0 0

# btrfs su l /
ID 257 gen 745235 top level 5 path ROOT
ID 258 gen 745235 top level 257 path home
ID 498 gen 744743 top level 5 path ROOT.snap
ID 501 gen 745043 top level 258 path home/home.snap

# cat /proc/self/mountinfo
17 0 0:17 /ROOT / rw,noatime shared:1 - btrfs /dev/sda6
rw,compress=lzo,space_cache,autodefrag
18 17 0:6 / /dev rw,relatime shared:2 - devtmpfs devtmpfs
rw,size=8060596k,nr_inodes=2015149,mode=755
19 17 0:20 / /sys rw,nosuid,nodev,noexec,relatime shared:5 - sysfs sysfs rw
20 17 0:4 / /proc rw,nosuid,nodev,noexec,relatime shared:8 - proc proc rw
21 18 0:21 / /dev/shm rw,nosuid,nodev shared:3 - tmpfs tmpfs rw
22 18 0:13 / /dev/pts rw,nosuid,noexec,relatime shared:4 - devpts
devpts rw,gid=5,mode=620,ptmxmode=000
23 17 0:22 / /run rw,nosuid,nodev shared:9 - tmpfs tmpfs rw,mode=755
24 19 0:23 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:6 - tmpfs
tmpfs ro,mode=755
25 24 0:24 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime
shared:7 - cgroup cgroup
rw,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
26 24 0:25 / /sys/fs/cgroup/net_cls,net_prio
rw,nosuid,nodev,noexec,relatime shared:10 - cgroup cgroup
rw,net_cls,net_prio
27 24 0:26 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime
shared:11 - cgroup cgroup rw,blkio
28 24 0:27 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime
shared:12 - cgroup cgroup rw,memory
29 24 0:28 / /sys/fs/cgroup/hugetlb rw,nosuid,nodev,noexec,relatime
shared:13 - cgroup cgroup rw,hugetlb
30 24 0:29 / /sys/fs/cgroup/cpu,cpuacct
rw,nosuid,nodev,noexec,relatime shared:14 - cgroup cgroup
rw,cpu,cpuacct
31 24 0:30 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime
shared:15 - cgroup cgroup rw,freezer
32 24 0:31 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime
shared:16 - cgroup cgroup rw,devices
33 24 0:32 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime
shared:17 - cgroup cgroup rw,perf_event
34 24 0:33 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime
shared:18 - cgroup cgroup rw,cpuset
35 20 0:34 / /proc/sys/fs/binfmt_misc rw,relatime shared:19 - autofs
systemd-1 rw,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct
36 19 0:7 / /sys/kernel/debug rw,relatime shared:20 - debugfs debugfs rw
37 18 0:35 / /dev/hugepages rw,relatime shared:21 - hugetlbfs hugetlbfs rw
38 17 0:36 / /tmp rw shared:22 - tmpfs tmpfs rw
39 18 0:15 / /dev/mqueue rw,relatime shared:23 - mqueue mqueue rw
64 17 0:22 / /var/run rw,nosuid,nodev shared:9 - tmpfs tmpfs rw,mode=755
244 23 0:45 / /run/user/1000 rw,nosuid,nodev,relatime shared:166 -
tmpfs tmpfs rw,size=1612540k,mode=700,uid=1000,gid=1000
245 64 0:45 / /var/run/user/1000 rw,nosuid,nodev,relatime shared:166 -
tmpfs tmpfs rw,size=1612540k,mode=700,uid=1000,gid=1000

Re: moving btrfs subvolumes to new disk

[Ryan Erato]

I do plan on physically replacing the current drive with the new one
and my fstab/boot comands use device. I never could get UUID or labels
to work, but that's another project.

However, this still leaves me unable to take advantage of btrfs
features for implementing an incremental backup solution to another
disk.
Ryan Erato
C. 414.630.5295
rerato@gmail.com
http://www.linkedin.com/in/ryanerato


On Sun, Mar 20, 2016 at 1:55 AM, Phantom Guy <no.real.person@gmail.com> wrote:
> You tried to hard.
>
> Build the new media If you need encryption or meets devices.
>
>
> Then add the new media to the whole filesystem.
>
>
> Then remove the old media from the filesystem.
>
>
> # btrfs device add /dev/sdb1 /mountpoint
>
> # btrfs device del /dev/sda1 /mountpoint
>
> Then sync the filesystem and wait.
>
> Once the old device ID no longer part of the filesystem it's done.
>
> When the sync finishes, the /dev/sda1 device is nill.
>
> If you've designed your fstsb and boot commands correctly the label or UUID
> has migrated so as long as you've prepped the disk with grub of whatever
> then you can move the disks with impunity.
>
> You don't even need to be in any sort of maintenance mode.
>
>
>>
>

Re: moving btrfs subvolumes to new disk

[Chris Murphy]

On Sat, Mar 19, 2016 at 4:58 PM, Ryan Erato <rerato@gmail.com> wrote:
> I'm having quite the time trying to move my current Gentoo install to
> an SSD. I first attempted Clonezilla, but that failed while cloning
> the btrfs partition. I then realized I could use btrfs send/receive.
>
> The partition has 2 subvolumes ROOT and ROOT/home. ROOT snapshots and
> sends without hitch, but /home consistently errors at the same point
> (from -vv output on btrfs send). btrfs send returns -2, no such file
> or directory, unexpected EOF in stream.

What's the exact command you're using for btrfs send receive for ROOT and home?


>
> # cat /etc/fstab
> /dev/sda4 /boot vfat noauto,noatime 1 2
> /dev/sda6 / btrfs defaults,noatime,compress=lzo,autodefrag,subvol=ROOT 0 0
> /dev/sda5 none swap sw 0 0
>
> # btrfs su l /
> ID 257 gen 745235 top level 5 path ROOT
> ID 258 gen 745235 top level 257 path home
> ID 498 gen 744743 top level 5 path ROOT.snap
> ID 501 gen 745043 top level 258 path home/home.snap

Nested subvolumes makes this more complicated in my opinion. You might
have better luck mounting subvolid=5 to /mnt and using a fully
qualified pathname for send.



-- 
Chris Murphy

Re: moving btrfs subvolumes to new disk

[Justin Brown]

I'm not an expert by any means, but I did a migration like this a few weeks ago.

The most consistent recommendation on this mailing list is to use the
newest kernels and btrfs-progs feasible. I did my migration using
Fedora 24 live media, which at the time was kernel ~4.3. I see your
btrfs-progs is a little old. Maybe the kernel is as well and has a
bug.

I know you tried a bunch of variations, but it would be helpful if you
posted the commands you've tried. Perhaps the most obvious problem
that could be occurring is trying to send a RW subvol, which is
illegal. I can't tell if you made a RO snapshot first, but your
success with ROOT indicates you're aware of this limitation. I'm
guessing that there's some problem with the destination path that
you're providing. The path should be the containing subvol where you
want it to go, not the destination name (i.e. btrfs receive
/var/media/backups/ not btrfs receive /var/media/backups/HOME).

Here's some send/receive commands that I've successfully used
recently. Maybe they'll point you in the right direction:

pull a RO snapshot from a remote system:

cd ~/ksp/backups
ssh 192.168.0.122 "sudo btrfs send
/home/justin/ksp/backups/2016-03-15-17:24" | sudo btrfs receive .
mv 2016-03-15-17:24 ../current

Note how I received into the backups directory and have no control
over the initial subvol name. I mv it to the proper location and name
afterwards.

move a RO snapshot between local file system:

cd /tmp/old-btrfs/
sudo btrfs subvol snap -r home home-snap
cd /tmp/new-btrfs/
sudo btrfs send /tmp/old-btrfs/home-snap | sudo btrfs receive .
sudo btrfs subvol snapshot home-snap home
sudo btrfs subvol delete home-snap

Fedora names it's /home subvol "home."

You *shouldn't* need to mess around with advanced mounting options to
get this to work.

On Sun, Mar 20, 2016 at 11:52 AM, Ryan Erato <rerato@gmail.com> wrote:
> I do plan on physically replacing the current drive with the new one
> and my fstab/boot comands use device. I never could get UUID or labels
> to work, but that's another project.
>
> However, this still leaves me unable to take advantage of btrfs
> features for implementing an incremental backup solution to another
> disk.
> Ryan Erato
> C. 414.630.5295
> rerato@gmail.com
> http://www.linkedin.com/in/ryanerato
>
>
> On Sun, Mar 20, 2016 at 1:55 AM, Phantom Guy <no.real.person@gmail.com> wrote:
>> You tried to hard.
>>
>> Build the new media If you need encryption or meets devices.
>>
>>
>> Then add the new media to the whole filesystem.
>>
>>
>> Then remove the old media from the filesystem.
>>
>>
>> # btrfs device add /dev/sdb1 /mountpoint
>>
>> # btrfs device del /dev/sda1 /mountpoint
>>
>> Then sync the filesystem and wait.
>>
>> Once the old device ID no longer part of the filesystem it's done.
>>
>> When the sync finishes, the /dev/sda1 device is nill.
>>
>> If you've designed your fstsb and boot commands correctly the label or UUID
>> has migrated so as long as you've prepped the disk with grub of whatever
>> then you can move the disks with impunity.
>>
>> You don't even need to be in any sort of maintenance mode.
>>
>>
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: moving btrfs subvolumes to new disk

[Ryan Erato]

Here's an example of what I've been trying:

" mount new ssd
root / # mount /dev/sdb6 /mnt/ssd/

" snapshot ROOT sub-volume mounted at /
root / # btrfs subvol snapshot -r / /ROOT.snap
Create a readonly snapshot of '/' in '//ROOT.snap'

root / # btrfs filesystem sync /
FSSync '/'

root / # btrfs subvol list /
ID 257 gen 747906 top level 5 path ROOT
ID 258 gen 747906 top level 257 path home
ID 487 gen 747893 top level 257 path ROOT.snap

root / # btrfs send /ROOT.snap/ | btrfs receive /mnt/ssd/
At subvol /ROOT.snap/
At subvol ROOT.snap

" snapshot home subvolume at /home
root / # btrfs subvol snapshot -r /home/ /home/home.snap
Create a readonly snapshot of '/home/' in '/home/home.snap'

root / # btrfs filesystem sync /home
FSSync '/home'

root / # btrfs subvol list /
ID 257 gen 747944 top level 5 path ROOT
ID 258 gen 747944 top level 257 path home
ID 487 gen 747893 top level 257 path ROOT.snap
ID 488 gen 747942 top level 258 path home/home.snap

root / # btrfs send /home/home.snap/ | btrfs receive /mnt/ssd/
At subvol /home/home.snap/
At subvol home.snap
ERROR: send ioctl failed with -2: No such file or directory
ERROR: unexpected EOF in stream.

root / # btrfs subvol list /mnt/ssd/
ID 257 gen 57 top level 5 path ROOT.snap
ID 285 gen 62 top level 5 path home.snap

I have also attempted to mount /dev/sdb6 with mount option
"subvol=ROOT" like I do in my system fstab for the current drive. I
have also tried saving the snapshot in "/" and "/home", with the same
results.

Sending "home.snap" to "/mnt/ssd" results in the -2 error. What is
peculiar, or possibly a red herring, is that it seems to fail at the
same point each time, at 4.39GB in to the transfer. Using verbose
output on receive it seems to process the files in the same order as
again, I see the same set of files just before it fails each and every
time.

I setup my system according to gentoo documentation, so I'm not sure
if I did something wrong with the initial btrfs partition setup that
is making this more difficult.


On Sun, Mar 20, 2016 at 12:31 PM, Chris Murphy <lists@colorremedies.com> wrote:
> On Sat, Mar 19, 2016 at 4:58 PM, Ryan Erato <rerato@gmail.com> wrote:
>> I'm having quite the time trying to move my current Gentoo install to
>> an SSD. I first attempted Clonezilla, but that failed while cloning
>> the btrfs partition. I then realized I could use btrfs send/receive.
>>
>> The partition has 2 subvolumes ROOT and ROOT/home. ROOT snapshots and
>> sends without hitch, but /home consistently errors at the same point
>> (from -vv output on btrfs send). btrfs send returns -2, no such file
>> or directory, unexpected EOF in stream.
>
> What's the exact command you're using for btrfs send receive for ROOT and home?
>
>
>>
>> # cat /etc/fstab
>> /dev/sda4 /boot vfat noauto,noatime 1 2
>> /dev/sda6 / btrfs defaults,noatime,compress=lzo,autodefrag,subvol=ROOT 0 0
>> /dev/sda5 none swap sw 0 0
>>
>> # btrfs su l /
>> ID 257 gen 745235 top level 5 path ROOT
>> ID 258 gen 745235 top level 257 path home
>> ID 498 gen 744743 top level 5 path ROOT.snap
>> ID 501 gen 745043 top level 258 path home/home.snap
>
> Nested subvolumes makes this more complicated in my opinion. You might
> have better luck mounting subvolid=5 to /mnt and using a fully
> qualified pathname for send.
>
>
>
> --
> Chris Murphy

Re: moving btrfs subvolumes to new disk

[Chris Murphy]

On Sun, Mar 20, 2016 at 10:34 PM, Ryan Erato <rerato@gmail.com> wrote:
.
>
> Sending "home.snap" to "/mnt/ssd" results in the -2 error. What is
> peculiar, or possibly a red herring, is that it seems to fail at the
> same point each time, at 4.39GB in to the transfer.



That's pretty suspicious. I didn't realize from the first description
that the command is doing something for a while before failing. I
thought it was failing immediately.

Try this:

btrfs send -vvv --no-data -f homesnap.btr home.snapshot

That will write out metadata only to a file, no receive. See if the
error still happens and if the extra v gives more info.

If it still fails with no more useful information then what I'd try
next is a btrfs check with the most recent btrfs-progs you can find.
If you're in need of a suggestion, this has btrfs-progs 4.4.1, I've
tested that it boots, it's got a published sha256 hash, and is served
over https. Yes, it's not even an alpha, but all you're doing is a
check, not a --repair, and no need to mount it (although that's
probably safe also, I've been doing it most of the weekend).
https://dl.fedoraproject.org/pub/alt/stage/24_Alpha-1.6/Workstation/x86_64/iso/
dd that iso file to a USB stick, it will destroy all data on the
stick, and then boot the computer, and switch to tty2 (control-alt-f2)
to get to a shell.

I think 'btrfs check > btrfscheck.txt' will output most of the results
to a text file. Often it misses the first few lines for whatever
reason. You can either 'fpaste <filename>' and then note the URL and
post it here, or you can scp the file elsewhere, if you have wired
ethernet connected.


-- 
Chris Murphy

Re: moving btrfs subvolumes to new disk

[Ryan Erato]

Finally got around to running the suggested commands. Same error with
the send, but not much output to help.  The check operation did seem
to reveal some potential issues. Here's the play-by-play along with
the file output from check:

[liveuser@localhost /]$ sudo btrfs check /dev/sda6 >
/home/liveuser/btrfscheck.txt
checking extents
checking free space cache
checking fs roots
root 257 inode 13324701 errors 200, dir isize wrong
root 258 inode 226392 errors 200, dir isize wrong
root 258 inode 236055 errors 2000, link count wrong
unresolved ref dir 226392 index 35 namelen 7 name LOG.old filetype 0
errors 3, no dir item, no dir index
root 258 inode 236273 errors 2000, link count wrong
root 258 inode 236276 errors 2000, link count wrong
unresolved ref dir 226392 index 39 namelen 15 name MANIFEST-000015
filetype 0 errors 3, no dir item, no dir index
root 258 inode 236277 errors 2000, link count wrong
unresolved ref dir 226392 index 41 namelen 7 name CURRENT filetype 0
errors 3, no dir item, no dir index
root 258 inode 240618 errors 2000, link count wrong
unresolved ref dir 226392 index 115 namelen 10 name 000089.log
filetype 0 errors 3, no dir item, no dir index
root 487 inode 13324701 errors 200, dir isize wrong
root 488 inode 226392 errors 200, dir isize wrong
root 488 inode 236055 errors 2000, link count wrong
unresolved ref dir 226392 index 35 namelen 7 name LOG.old filetype 0
errors 3, no dir item, no dir index
root 488 inode 236273 errors 2000, link count wrong
root 488 inode 236276 errors 2000, link count wrong
unresolved ref dir 226392 index 39 namelen 15 name MANIFEST-000015
filetype 0 errors 3, no dir item, no dir index
root 488 inode 236277 errors 2000, link count wrong
unresolved ref dir 226392 index 41 namelen 7 name CURRENT filetype 0
errors 3, no dir item, no dir index
root 488 inode 240618 errors 2000, link count wrong
unresolved ref dir 226392 index 115 namelen 10 name 000089.log
filetype 0 errors 3, no dir item, no dir index


" btrfscheck.txt
Checking filesystem on /dev/sda6
UUID: 6bb38bce-d824-4b9c-8b03-adad460c0f97
found 79333650514 bytes used err is 1
total csum bytes: 60906940
total tree bytes: 1530494976
total fs tree bytes: 1392934912
total extent tree bytes: 59506688
btree space waste bytes: 343045471
file data blocks allocated: 97137004544
 referenced 85008084992


[liveuser@localhost /]$ sudo mount /dev/sda6 /mnt/hdd

[liveuser@localhost /]$ sudo btrfs send -vvv --no-data -f homesnap.btr
/mnt/hdd/home/home.snap/
Mode NO_FILE_DATA enabled
At subvol /mnt/hdd/home/home.snap/
ERROR: send ioctl failed with -2: No such file or directory



On Sun, Mar 20, 2016 at 10:42 PM, Chris Murphy <lists@colorremedies.com> wrote:
> On Sun, Mar 20, 2016 at 10:34 PM, Ryan Erato <rerato@gmail.com> wrote:
> .
>>
>> Sending "home.snap" to "/mnt/ssd" results in the -2 error. What is
>> peculiar, or possibly a red herring, is that it seems to fail at the
>> same point each time, at 4.39GB in to the transfer.
>
>
>
> That's pretty suspicious. I didn't realize from the first description
> that the command is doing something for a while before failing. I
> thought it was failing immediately.
>
> Try this:
>
> btrfs send -vvv --no-data -f homesnap.btr home.snapshot
>
> That will write out metadata only to a file, no receive. See if the
> error still happens and if the extra v gives more info.
>
> If it still fails with no more useful information then what I'd try
> next is a btrfs check with the most recent btrfs-progs you can find.
> If you're in need of a suggestion, this has btrfs-progs 4.4.1, I've
> tested that it boots, it's got a published sha256 hash, and is served
> over https. Yes, it's not even an alpha, but all you're doing is a
> check, not a --repair, and no need to mount it (although that's
> probably safe also, I've been doing it most of the weekend).
> https://dl.fedoraproject.org/pub/alt/stage/24_Alpha-1.6/Workstation/x86_64/iso/
> dd that iso file to a USB stick, it will destroy all data on the
> stick, and then boot the computer, and switch to tty2 (control-alt-f2)
> to get to a shell.
>
> I think 'btrfs check > btrfscheck.txt' will output most of the results
> to a text file. Often it misses the first few lines for whatever
> reason. You can either 'fpaste <filename>' and then note the URL and
> post it here, or you can scp the file elsewhere, if you have wired
> ethernet connected.
>
>
> --
> Chris Murphy

Re: moving btrfs subvolumes to new disk

[Chris Murphy]

On Tue, Mar 22, 2016 at 7:40 PM, Ryan Erato <rerato@gmail.com> wrote:
> Finally got around to running the suggested commands. Same error with
> the send, but not much output to help.  The check operation did seem
> to reveal some potential issues. Here's the play-by-play along with
> the file output from check:
>
> [liveuser@localhost /]$ sudo btrfs check /dev/sda6 >
> /home/liveuser/btrfscheck.txt
> checking extents
> checking free space cache
> checking fs roots
> root 257 inode 13324701 errors 200, dir isize wrong
> root 258 inode 226392 errors 200, dir isize wrong
> root 258 inode 236055 errors 2000, link count wrong
> unresolved ref dir 226392 index 35 namelen 7 name LOG.old filetype 0
> errors 3, no dir item, no dir index
> root 258 inode 236273 errors 2000, link count wrong
> root 258 inode 236276 errors 2000, link count wrong
> unresolved ref dir 226392 index 39 namelen 15 name MANIFEST-000015
> filetype 0 errors 3, no dir item, no dir index
> root 258 inode 236277 errors 2000, link count wrong
> unresolved ref dir 226392 index 41 namelen 7 name CURRENT filetype 0
> errors 3, no dir item, no dir index
> root 258 inode 240618 errors 2000, link count wrong
> unresolved ref dir 226392 index 115 namelen 10 name 000089.log
> filetype 0 errors 3, no dir item, no dir index
> root 487 inode 13324701 errors 200, dir isize wrong
> root 488 inode 226392 errors 200, dir isize wrong
> root 488 inode 236055 errors 2000, link count wrong
> unresolved ref dir 226392 index 35 namelen 7 name LOG.old filetype 0
> errors 3, no dir item, no dir index
> root 488 inode 236273 errors 2000, link count wrong
> root 488 inode 236276 errors 2000, link count wrong
> unresolved ref dir 226392 index 39 namelen 15 name MANIFEST-000015
> filetype 0 errors 3, no dir item, no dir index
> root 488 inode 236277 errors 2000, link count wrong
> unresolved ref dir 226392 index 41 namelen 7 name CURRENT filetype 0
> errors 3, no dir item, no dir index
> root 488 inode 240618 errors 2000, link count wrong
> unresolved ref dir 226392 index 115 namelen 10 name 000089.log
> filetype 0 errors 3, no dir item, no dir index

OK so now the question is if 'btrfs check --repair' can fix this, and
what version to use? 4.4.1 or 4.5.0? Based on the changelog, you can
probably use either version. And I think it should be safe. But, you
should still have backups seeing as you can mount the volume.


>
> [liveuser@localhost /]$ sudo mount /dev/sda6 /mnt/hdd
>
> [liveuser@localhost /]$ sudo btrfs send -vvv --no-data -f homesnap.btr
> /mnt/hdd/home/home.snap/
> Mode NO_FILE_DATA enabled
> At subvol /mnt/hdd/home/home.snap/
> ERROR: send ioctl failed with -2: No such file or directory

OK so there's something off with the metadata and it's not going to do
a send as a result is what this sounds like to me.


-- 
Chris Murphy

Re: moving btrfs subvolumes to new disk

[Ryan Erato]

Success! Using the same ISO you previously linked to, I ran 'btrfs
check --repair', did another check which actually revealed many new
issues, ran a repair again and after that successive checks showed no
signs of other issues. I was able to successfully send my 'home'
subvolume to the SSD and wow, huge difference with otherwise little
effort.

Thanks to you and everybody else for helping me resolve this issue.



On Tue, Mar 22, 2016 at 8:34 PM, Chris Murphy <lists@colorremedies.com> wrote:
> On Tue, Mar 22, 2016 at 7:40 PM, Ryan Erato <rerato@gmail.com> wrote:
>> Finally got around to running the suggested commands. Same error with
>> the send, but not much output to help.  The check operation did seem
>> to reveal some potential issues. Here's the play-by-play along with
>> the file output from check:
>>
>> [liveuser@localhost /]$ sudo btrfs check /dev/sda6 >
>> /home/liveuser/btrfscheck.txt
>> checking extents
>> checking free space cache
>> checking fs roots
>> root 257 inode 13324701 errors 200, dir isize wrong
>> root 258 inode 226392 errors 200, dir isize wrong
>> root 258 inode 236055 errors 2000, link count wrong
>> unresolved ref dir 226392 index 35 namelen 7 name LOG.old filetype 0
>> errors 3, no dir item, no dir index
>> root 258 inode 236273 errors 2000, link count wrong
>> root 258 inode 236276 errors 2000, link count wrong
>> unresolved ref dir 226392 index 39 namelen 15 name MANIFEST-000015
>> filetype 0 errors 3, no dir item, no dir index
>> root 258 inode 236277 errors 2000, link count wrong
>> unresolved ref dir 226392 index 41 namelen 7 name CURRENT filetype 0
>> errors 3, no dir item, no dir index
>> root 258 inode 240618 errors 2000, link count wrong
>> unresolved ref dir 226392 index 115 namelen 10 name 000089.log
>> filetype 0 errors 3, no dir item, no dir index
>> root 487 inode 13324701 errors 200, dir isize wrong
>> root 488 inode 226392 errors 200, dir isize wrong
>> root 488 inode 236055 errors 2000, link count wrong
>> unresolved ref dir 226392 index 35 namelen 7 name LOG.old filetype 0
>> errors 3, no dir item, no dir index
>> root 488 inode 236273 errors 2000, link count wrong
>> root 488 inode 236276 errors 2000, link count wrong
>> unresolved ref dir 226392 index 39 namelen 15 name MANIFEST-000015
>> filetype 0 errors 3, no dir item, no dir index
>> root 488 inode 236277 errors 2000, link count wrong
>> unresolved ref dir 226392 index 41 namelen 7 name CURRENT filetype 0
>> errors 3, no dir item, no dir index
>> root 488 inode 240618 errors 2000, link count wrong
>> unresolved ref dir 226392 index 115 namelen 10 name 000089.log
>> filetype 0 errors 3, no dir item, no dir index
>
> OK so now the question is if 'btrfs check --repair' can fix this, and
> what version to use? 4.4.1 or 4.5.0? Based on the changelog, you can
> probably use either version. And I think it should be safe. But, you
> should still have backups seeing as you can mount the volume.
>
>
>>
>> [liveuser@localhost /]$ sudo mount /dev/sda6 /mnt/hdd
>>
>> [liveuser@localhost /]$ sudo btrfs send -vvv --no-data -f homesnap.btr
>> /mnt/hdd/home/home.snap/
>> Mode NO_FILE_DATA enabled
>> At subvol /mnt/hdd/home/home.snap/
>> ERROR: send ioctl failed with -2: No such file or directory
>
> OK so there's something off with the metadata and it's not going to do
> a send as a result is what this sounds like to me.
>
>
> --
> Chris Murphy

Re: moving btrfs subvolumes to new disk

[Chris Murphy]

On Wed, Mar 23, 2016 at 8:08 PM, Ryan Erato <rerato@gmail.com> wrote:
> Success! Using the same ISO you previously linked to, I ran 'btrfs
> check --repair', did another check which actually revealed many new
> issues, ran a repair again and after that successive checks showed no
> signs of other issues. I was able to successfully send my 'home'
> subvolume to the SSD and wow, huge difference with otherwise little
> effort.
>
> Thanks to you and everybody else for helping me resolve this issue.

Yay, good news!


-- 
Chris Murphy