* receive snapshot, complains about missing file
@ 2016-04-29 20:01 Alexander Fougner
2016-04-29 20:17 ` Chris Murphy
0 siblings, 1 reply; 10+ messages in thread
From: Alexander Fougner @ 2016-04-29 20:01 UTC (permalink / raw)
To: linux-btrfs
Hello,
Kernel 4.4.x and progs 4.5.1 on both client/host.
As the topic says, I noticed that my automatic backus stopped working
a while back. The cause seems to be related to snapshot
inconsistencies.
WARNING: [btrfs send/receive]
(send=/mnt/btrfs_pool/__snapshots/@home.20160404,
receive=/srv/backup/optimus) At subvol
/mnt/btrfs_pool/__snapshots/@home.20160404
WARNING: [btrfs send/receive]
(send=/mnt/btrfs_pool/__snapshots/@home.20160404,
receive=/srv/backup/optimus) At snapshot @home.20160404
ERROR: cannot open
srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
No such file or directory
ERROR: Failed to send/receive btrfs subvolume:
/mnt/btrfs_pool/__snapshots/@home.20160404
[/mnt/btrfs_pool/__snapshots/@home.20160403] ->
fractal:/srv/backup/optimus
WARNING: Deleted partially received (garbled) subvolume:
fractal:/srv/backup/optimus/@home.20160404
ERROR: Error while resuming backups, aborting
However, the file exists in all relevant places.
This is the relevant part from btrfs receive -vvv, before it stops working.
rename o1283816-161574-0 -> alex/Android/LNU/Ass1
(kopia)/.gradle/2.8/taskArtifacts/cache.properties
utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
truncate alex/Android/LNU/Ass1
(kopia)/.gradle/2.8/taskArtifacts/cache.properties size=30
chown alex/Android/LNU/Ass1
(kopia)/.gradle/2.8/taskArtifacts/cache.properties - uid=1000,
gid=1000
chmod alex/Android/LNU/Ass1
(kopia)/.gradle/2.8/taskArtifacts/cache.properties - mode=0664
utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts/cache.properties
mkfile o1283817-161574-0
rename o1283817-161574-0 -> alex/Android/LNU/Ass1
(kopia)/.gradle/2.8/taskArtifacts/taskArtifacts.bin
utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
ERROR: cannot open
srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
No such file or directory
Any pointers on how to proceed are much appreciated.
Best regards,
Alex
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: receive snapshot, complains about missing file
2016-04-29 20:01 receive snapshot, complains about missing file Alexander Fougner
@ 2016-04-29 20:17 ` Chris Murphy
2016-04-29 20:20 ` Alexander Fougner
0 siblings, 1 reply; 10+ messages in thread
From: Chris Murphy @ 2016-04-29 20:17 UTC (permalink / raw)
To: Alexander Fougner; +Cc: linux-btrfs
On Fri, Apr 29, 2016 at 2:01 PM, Alexander Fougner <fougner89@gmail.com> wrote:
> Hello,
>
> Kernel 4.4.x and progs 4.5.1 on both client/host.
>
> As the topic says, I noticed that my automatic backus stopped working
> a while back. The cause seems to be related to snapshot
> inconsistencies.
>
> WARNING: [btrfs send/receive]
> (send=/mnt/btrfs_pool/__snapshots/@home.20160404,
> receive=/srv/backup/optimus) At subvol
> /mnt/btrfs_pool/__snapshots/@home.20160404
> WARNING: [btrfs send/receive]
> (send=/mnt/btrfs_pool/__snapshots/@home.20160404,
> receive=/srv/backup/optimus) At snapshot @home.20160404
> ERROR: cannot open
> srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
> No such file or directory
> ERROR: Failed to send/receive btrfs subvolume:
> /mnt/btrfs_pool/__snapshots/@home.20160404
> [/mnt/btrfs_pool/__snapshots/@home.20160403] ->
> fractal:/srv/backup/optimus
> WARNING: Deleted partially received (garbled) subvolume:
> fractal:/srv/backup/optimus/@home.20160404
> ERROR: Error while resuming backups, aborting
>
> However, the file exists in all relevant places.
>
> This is the relevant part from btrfs receive -vvv, before it stops working.
>
> rename o1283816-161574-0 -> alex/Android/LNU/Ass1
> (kopia)/.gradle/2.8/taskArtifacts/cache.properties
> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
> truncate alex/Android/LNU/Ass1
> (kopia)/.gradle/2.8/taskArtifacts/cache.properties size=30
> chown alex/Android/LNU/Ass1
> (kopia)/.gradle/2.8/taskArtifacts/cache.properties - uid=1000,
> gid=1000
> chmod alex/Android/LNU/Ass1
> (kopia)/.gradle/2.8/taskArtifacts/cache.properties - mode=0664
> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts/cache.properties
> mkfile o1283817-161574-0
> rename o1283817-161574-0 -> alex/Android/LNU/Ass1
> (kopia)/.gradle/2.8/taskArtifacts/taskArtifacts.bin
> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
> ERROR: cannot open
> srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
> No such file or directory
>
>
Do scrub and btrfs check (no repair) complete without errors?
--
Chris Murphy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: receive snapshot, complains about missing file
2016-04-29 20:17 ` Chris Murphy
@ 2016-04-29 20:20 ` Alexander Fougner
2016-04-29 20:28 ` Chris Murphy
0 siblings, 1 reply; 10+ messages in thread
From: Alexander Fougner @ 2016-04-29 20:20 UTC (permalink / raw)
To: Chris Murphy; +Cc: linux-btrfs
2016-04-29 22:17 GMT+02:00 Chris Murphy <lists@colorremedies.com>:
> On Fri, Apr 29, 2016 at 2:01 PM, Alexander Fougner <fougner89@gmail.com> wrote:
>> Hello,
>>
>> Kernel 4.4.x and progs 4.5.1 on both client/host.
>>
>> As the topic says, I noticed that my automatic backus stopped working
>> a while back. The cause seems to be related to snapshot
>> inconsistencies.
>>
>> WARNING: [btrfs send/receive]
>> (send=/mnt/btrfs_pool/__snapshots/@home.20160404,
>> receive=/srv/backup/optimus) At subvol
>> /mnt/btrfs_pool/__snapshots/@home.20160404
>> WARNING: [btrfs send/receive]
>> (send=/mnt/btrfs_pool/__snapshots/@home.20160404,
>> receive=/srv/backup/optimus) At snapshot @home.20160404
>> ERROR: cannot open
>> srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
>> No such file or directory
>> ERROR: Failed to send/receive btrfs subvolume:
>> /mnt/btrfs_pool/__snapshots/@home.20160404
>> [/mnt/btrfs_pool/__snapshots/@home.20160403] ->
>> fractal:/srv/backup/optimus
>> WARNING: Deleted partially received (garbled) subvolume:
>> fractal:/srv/backup/optimus/@home.20160404
>> ERROR: Error while resuming backups, aborting
>>
>> However, the file exists in all relevant places.
>>
>> This is the relevant part from btrfs receive -vvv, before it stops working.
>>
>> rename o1283816-161574-0 -> alex/Android/LNU/Ass1
>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties
>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
>> truncate alex/Android/LNU/Ass1
>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties size=30
>> chown alex/Android/LNU/Ass1
>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties - uid=1000,
>> gid=1000
>> chmod alex/Android/LNU/Ass1
>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties - mode=0664
>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts/cache.properties
>> mkfile o1283817-161574-0
>> rename o1283817-161574-0 -> alex/Android/LNU/Ass1
>> (kopia)/.gradle/2.8/taskArtifacts/taskArtifacts.bin
>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
>> ERROR: cannot open
>> srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
>> No such file or directory
>>
>>
>
> Do scrub and btrfs check (no repair) complete without errors?
>
Scrub does, don't know about btrfs check yet. Will run check and report back.
>
> --
> Chris Murphy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: receive snapshot, complains about missing file
2016-04-29 20:20 ` Alexander Fougner
@ 2016-04-29 20:28 ` Chris Murphy
2016-04-30 10:27 ` Alexander Fougner
2016-04-30 10:28 ` Alexander Fougner
0 siblings, 2 replies; 10+ messages in thread
From: Chris Murphy @ 2016-04-29 20:28 UTC (permalink / raw)
To: Alexander Fougner; +Cc: Chris Murphy, linux-btrfs
On Fri, Apr 29, 2016 at 2:20 PM, Alexander Fougner <fougner89@gmail.com> wrote:
> 2016-04-29 22:17 GMT+02:00 Chris Murphy <lists@colorremedies.com>:
>> On Fri, Apr 29, 2016 at 2:01 PM, Alexander Fougner <fougner89@gmail.com> wrote:
>>> Hello,
>>>
>>> Kernel 4.4.x and progs 4.5.1 on both client/host.
>>>
>>> As the topic says, I noticed that my automatic backus stopped working
>>> a while back. The cause seems to be related to snapshot
>>> inconsistencies.
>>>
>>> WARNING: [btrfs send/receive]
>>> (send=/mnt/btrfs_pool/__snapshots/@home.20160404,
>>> receive=/srv/backup/optimus) At subvol
>>> /mnt/btrfs_pool/__snapshots/@home.20160404
>>> WARNING: [btrfs send/receive]
>>> (send=/mnt/btrfs_pool/__snapshots/@home.20160404,
>>> receive=/srv/backup/optimus) At snapshot @home.20160404
>>> ERROR: cannot open
>>> srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
>>> No such file or directory
>>> ERROR: Failed to send/receive btrfs subvolume:
>>> /mnt/btrfs_pool/__snapshots/@home.20160404
>>> [/mnt/btrfs_pool/__snapshots/@home.20160403] ->
>>> fractal:/srv/backup/optimus
>>> WARNING: Deleted partially received (garbled) subvolume:
>>> fractal:/srv/backup/optimus/@home.20160404
>>> ERROR: Error while resuming backups, aborting
>>>
>>> However, the file exists in all relevant places.
>>>
>>> This is the relevant part from btrfs receive -vvv, before it stops working.
>>>
>>> rename o1283816-161574-0 -> alex/Android/LNU/Ass1
>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties
>>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
>>> truncate alex/Android/LNU/Ass1
>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties size=30
>>> chown alex/Android/LNU/Ass1
>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties - uid=1000,
>>> gid=1000
>>> chmod alex/Android/LNU/Ass1
>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties - mode=0664
>>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts/cache.properties
>>> mkfile o1283817-161574-0
>>> rename o1283817-161574-0 -> alex/Android/LNU/Ass1
>>> (kopia)/.gradle/2.8/taskArtifacts/taskArtifacts.bin
>>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
>>> ERROR: cannot open
>>> srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
>>> No such file or directory
>>>
>>>
>>
>> Do scrub and btrfs check (no repair) complete without errors?
>>
> Scrub does, don't know about btrfs check yet. Will run check and report back.
And actually it applies to both source and destination file systems.
Chances are it's the receive one that has the problem, but better to
be certain. Maybe send is sending something (?) that receive isn't
expecting and the problem is actually there?
--
Chris Murphy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: receive snapshot, complains about missing file
2016-04-29 20:28 ` Chris Murphy
@ 2016-04-30 10:27 ` Alexander Fougner
2016-04-30 10:28 ` Alexander Fougner
1 sibling, 0 replies; 10+ messages in thread
From: Alexander Fougner @ 2016-04-30 10:27 UTC (permalink / raw)
To: Chris Murphy; +Cc: linux-btrfs
2016-04-29 22:28 GMT+02:00 Chris Murphy <lists@colorremedies.com>:
> On Fri, Apr 29, 2016 at 2:20 PM, Alexander Fougner <fougner89@gmail.com> wrote:
>> 2016-04-29 22:17 GMT+02:00 Chris Murphy <lists@colorremedies.com>:
>>> On Fri, Apr 29, 2016 at 2:01 PM, Alexander Fougner <fougner89@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> Kernel 4.4.x and progs 4.5.1 on both client/host.
>>>>
>>>> As the topic says, I noticed that my automatic backus stopped working
>>>> a while back. The cause seems to be related to snapshot
>>>> inconsistencies.
>>>>
>>>> WARNING: [btrfs send/receive]
>>>> (send=/mnt/btrfs_pool/__snapshots/@home.20160404,
>>>> receive=/srv/backup/optimus) At subvol
>>>> /mnt/btrfs_pool/__snapshots/@home.20160404
>>>> WARNING: [btrfs send/receive]
>>>> (send=/mnt/btrfs_pool/__snapshots/@home.20160404,
>>>> receive=/srv/backup/optimus) At snapshot @home.20160404
>>>> ERROR: cannot open
>>>> srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
>>>> No such file or directory
>>>> ERROR: Failed to send/receive btrfs subvolume:
>>>> /mnt/btrfs_pool/__snapshots/@home.20160404
>>>> [/mnt/btrfs_pool/__snapshots/@home.20160403] ->
>>>> fractal:/srv/backup/optimus
>>>> WARNING: Deleted partially received (garbled) subvolume:
>>>> fractal:/srv/backup/optimus/@home.20160404
>>>> ERROR: Error while resuming backups, aborting
>>>>
>>>> However, the file exists in all relevant places.
>>>>
>>>> This is the relevant part from btrfs receive -vvv, before it stops working.
>>>>
>>>> rename o1283816-161574-0 -> alex/Android/LNU/Ass1
>>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties
>>>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
>>>> truncate alex/Android/LNU/Ass1
>>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties size=30
>>>> chown alex/Android/LNU/Ass1
>>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties - uid=1000,
>>>> gid=1000
>>>> chmod alex/Android/LNU/Ass1
>>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties - mode=0664
>>>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts/cache.properties
>>>> mkfile o1283817-161574-0
>>>> rename o1283817-161574-0 -> alex/Android/LNU/Ass1
>>>> (kopia)/.gradle/2.8/taskArtifacts/taskArtifacts.bin
>>>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
>>>> ERROR: cannot open
>>>> srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
>>>> No such file or directory
>>>>
>>>>
>>>
>>> Do scrub and btrfs check (no repair) complete without errors?
>>>
>> Scrub does, don't know about btrfs check yet. Will run check and report back.
>
The receive-side FS outputs
sudo btrfs check /dev/sde
Couldn't open file system
The send side
> And actually it applies to both source and destination file systems.
Yep, both have 0 errors for scrub.
> Chances are it's the receive one that has the problem, but better to
> be certain. Maybe send is sending something (?) that receive isn't
> expecting and the problem is actually there?
>
>
> --
> Chris Murphy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: receive snapshot, complains about missing file
2016-04-29 20:28 ` Chris Murphy
2016-04-30 10:27 ` Alexander Fougner
@ 2016-04-30 10:28 ` Alexander Fougner
2016-04-30 10:49 ` Duncan
1 sibling, 1 reply; 10+ messages in thread
From: Alexander Fougner @ 2016-04-30 10:28 UTC (permalink / raw)
To: Chris Murphy; +Cc: linux-btrfs
Heh, sorry about the noise!
2016-04-29 22:28 GMT+02:00 Chris Murphy <lists@colorremedies.com>:
> On Fri, Apr 29, 2016 at 2:20 PM, Alexander Fougner <fougner89@gmail.com> wrote:
>> 2016-04-29 22:17 GMT+02:00 Chris Murphy <lists@colorremedies.com>:
>>> On Fri, Apr 29, 2016 at 2:01 PM, Alexander Fougner <fougner89@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> Kernel 4.4.x and progs 4.5.1 on both client/host.
>>>>
>>>> As the topic says, I noticed that my automatic backus stopped working
>>>> a while back. The cause seems to be related to snapshot
>>>> inconsistencies.
>>>>
>>>> WARNING: [btrfs send/receive]
>>>> (send=/mnt/btrfs_pool/__snapshots/@home.20160404,
>>>> receive=/srv/backup/optimus) At subvol
>>>> /mnt/btrfs_pool/__snapshots/@home.20160404
>>>> WARNING: [btrfs send/receive]
>>>> (send=/mnt/btrfs_pool/__snapshots/@home.20160404,
>>>> receive=/srv/backup/optimus) At snapshot @home.20160404
>>>> ERROR: cannot open
>>>> srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
>>>> No such file or directory
>>>> ERROR: Failed to send/receive btrfs subvolume:
>>>> /mnt/btrfs_pool/__snapshots/@home.20160404
>>>> [/mnt/btrfs_pool/__snapshots/@home.20160403] ->
>>>> fractal:/srv/backup/optimus
>>>> WARNING: Deleted partially received (garbled) subvolume:
>>>> fractal:/srv/backup/optimus/@home.20160404
>>>> ERROR: Error while resuming backups, aborting
>>>>
>>>> However, the file exists in all relevant places.
>>>>
>>>> This is the relevant part from btrfs receive -vvv, before it stops working.
>>>>
>>>> rename o1283816-161574-0 -> alex/Android/LNU/Ass1
>>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties
>>>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
>>>> truncate alex/Android/LNU/Ass1
>>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties size=30
>>>> chown alex/Android/LNU/Ass1
>>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties - uid=1000,
>>>> gid=1000
>>>> chmod alex/Android/LNU/Ass1
>>>> (kopia)/.gradle/2.8/taskArtifacts/cache.properties - mode=0664
>>>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts/cache.properties
>>>> mkfile o1283817-161574-0
>>>> rename o1283817-161574-0 -> alex/Android/LNU/Ass1
>>>> (kopia)/.gradle/2.8/taskArtifacts/taskArtifacts.bin
>>>> utimes alex/Android/LNU/Ass1 (kopia)/.gradle/2.8/taskArtifacts
>>>> ERROR: cannot open
>>>> srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
>>>> No such file or directory
>>>>
>>>>
>>>
>>> Do scrub and btrfs check (no repair) complete without errors?
Send side
sudo btrfs check /dev/sda1
Checking filesystem on /dev/sda1
UUID: 2deed283-bc4e-4d8b-bc6c-9ca035d90342
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 106157568114 bytes used err is 0
total csum bytes: 102001828
total tree bytes: 1585774592
total fs tree bytes: 1387134976
total extent tree bytes: 74448896
btree space waste bytes: 348106294
file data blocks allocated: 272060542976
referenced 190188584960
Receive side only outputs this:
sudo btrfs check -p /dev/sdc
Couldn't open file system
Scrub completes without errors on both FS.
>>>
>> Scrub does, don't know about btrfs check yet. Will run check and report back.
>
> And actually it applies to both source and destination file systems.
> Chances are it's the receive one that has the problem, but better to
> be certain. Maybe send is sending something (?) that receive isn't
> expecting and the problem is actually there?
>
>
> --
> Chris Murphy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: receive snapshot, complains about missing file
2016-04-30 10:28 ` Alexander Fougner
@ 2016-04-30 10:49 ` Duncan
2016-04-30 10:55 ` Alexander Fougner
0 siblings, 1 reply; 10+ messages in thread
From: Duncan @ 2016-04-30 10:49 UTC (permalink / raw)
To: linux-btrfs
Alexander Fougner posted on Sat, 30 Apr 2016 12:28:34 +0200 as excerpted:
>>>> Do scrub and btrfs check (no repair) complete without errors?
>
> Send side
>
> sudo btrfs check /dev/sda1
> Checking filesystem on /dev/sda1
[... but no errors]
> Receive side only outputs this:
> sudo btrfs check -p /dev/sdc
> Couldn't open file system
It wasn't mounted at the time, right?
Cuz btrfs check won't work with a mounted filesystem.
Of course you'll need to be root to access the device as well,
but that's pretty much a given.
> Scrub completes without errors on both FS.
That's good. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: receive snapshot, complains about missing file
2016-04-30 10:49 ` Duncan
@ 2016-04-30 10:55 ` Alexander Fougner
2016-04-30 11:28 ` Duncan
0 siblings, 1 reply; 10+ messages in thread
From: Alexander Fougner @ 2016-04-30 10:55 UTC (permalink / raw)
To: Duncan; +Cc: linux-btrfs
2016-04-30 12:49 GMT+02:00 Duncan <1i5t5.duncan@cox.net>:
> Alexander Fougner posted on Sat, 30 Apr 2016 12:28:34 +0200 as excerpted:
>
>>>>> Do scrub and btrfs check (no repair) complete without errors?
>>
>> Send side
>>
>> sudo btrfs check /dev/sda1
>> Checking filesystem on /dev/sda1
>
> [... but no errors]
>
>> Receive side only outputs this:
>> sudo btrfs check -p /dev/sdc
>> Couldn't open file system
>
> It wasn't mounted at the time, right?
Nope
>
> Cuz btrfs check won't work with a mounted filesystem.
>
> Of course you'll need to be root to access the device as well,
> but that's pretty much a given.
I think sudo should do that, right?
>
>
>> Scrub completes without errors on both FS.
>
> That's good. =:^)
>
> --
> Duncan - List replies preferred. No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." Richard Stallman
>
> --
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: receive snapshot, complains about missing file
2016-04-30 10:55 ` Alexander Fougner
@ 2016-04-30 11:28 ` Duncan
2016-05-03 19:00 ` Alexander Fougner
0 siblings, 1 reply; 10+ messages in thread
From: Duncan @ 2016-04-30 11:28 UTC (permalink / raw)
To: linux-btrfs
Alexander Fougner posted on Sat, 30 Apr 2016 12:55:06 +0200 as excerpted:
>>> Receive side only outputs this:
>>> sudo btrfs check -p /dev/sdc Couldn't open file system
>>
>> It wasn't mounted at the time, right?
>
> Nope
>
>
>> Cuz btrfs check won't work with a mounted filesystem.
>>
>> Of course you'll need to be root to access the device as well,
>> but that's pretty much a given.
>
> I think sudo should do that, right?
Yes.
I wonder then why it couldn't access it?
Just to be sure, since I didn't think to ask the first time and with
subvolumes it's possible to mount other subvolumes and possibly forget
that they're actually part of the same filesystem, you didn't have /any/
subvolumes of that filesystem mounted, right?
What does btrfs fi show say about the filesystem?
I'm assuming it's mountable. Does a mount and umount then let it be
btrfs checked? On the other end of things, what about a reboot and btrfs
device scan, then btrfs check?
If it's not the low-hanging fruit like that, perhaps check is keying off
the same error that receive is, but I haven't the foggiest what the
problem would be.
I guess another possibility would be that btrfs check is violating some
sort of security policy such as selinux. I don't run anything of that
nature here so know little more about it beyond the possibility, but from
previous posts I think Chris Murphy has at some experience in that area.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: receive snapshot, complains about missing file
2016-04-30 11:28 ` Duncan
@ 2016-05-03 19:00 ` Alexander Fougner
0 siblings, 0 replies; 10+ messages in thread
From: Alexander Fougner @ 2016-05-03 19:00 UTC (permalink / raw)
To: Duncan; +Cc: linux-btrfs
2016-04-30 13:28 GMT+02:00 Duncan <1i5t5.duncan@cox.net>:
> Alexander Fougner posted on Sat, 30 Apr 2016 12:55:06 +0200 as excerpted:
>
>>>> Receive side only outputs this:
>>>> sudo btrfs check -p /dev/sdc Couldn't open file system
>>>
>>> It wasn't mounted at the time, right?
>>
>> Nope
>>
>>
>>> Cuz btrfs check won't work with a mounted filesystem.
>>>
>>> Of course you'll need to be root to access the device as well,
>>> but that's pretty much a given.
>>
>> I think sudo should do that, right?
>
> Yes.
>
> I wonder then why it couldn't access it?
>
Me too!
It worked with a liveusb though. Btrfs-progs 4.4
sudo btrfs check /dev/sdc
Checking filesystem on /dev/sdc
UUID: 666172ff-0adb-45e8-8640-4feed682f378
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 2334784469221 bytes used err is 0
total csum bytes: 2243595764
total tree bytes: 8267939840
total fs tree bytes: 5431869440
total extent tree bytes: 271794176
btree space waste bytes: 1221110549
file data blocks allocated: 146702044540928
referenced 2388234321920
Looks good to me.
Also, it works to resend the complete chain of snapshots to a new FS.
However, deleting the complete chain of snapshots on the trouble-FS
and resending everything still results in the same error.
> Just to be sure, since I didn't think to ask the first time and with
> subvolumes it's possible to mount other subvolumes and possibly forget
> that they're actually part of the same filesystem, you didn't have /any/
> subvolumes of that filesystem mounted, right?
I'm pretty sure nothing else was mounted. Besides, that should output
a different error message, warning us about the mounted FS.
>
> What does btrfs fi show say about the filesystem?
>
Label: 'storage' uuid: 666172ff-0adb-45e8-8640-4feed682f378
Total devices 2 FS bytes used 2.12TiB
devid 3 size 2.73TiB used 2.23TiB path /dev/sde
devid 4 size 2.73TiB used 2.23TiB path /dev/sdc
> I'm assuming it's mountable. Does a mount and umount then let it be
> btrfs checked? On the other end of things, what about a reboot and btrfs
> device scan, then btrfs check?
>
> If it's not the low-hanging fruit like that, perhaps check is keying off
> the same error that receive is, but I haven't the foggiest what the
> problem would be.
>
> I guess another possibility would be that btrfs check is violating some
> sort of security policy such as selinux. I don't run anything of that
> nature here so know little more about it beyond the possibility, but from
> previous posts I think Chris Murphy has at some experience in that area.
>
> --
> Duncan - List replies preferred. No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." Richard Stallman
>
> --
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-05-03 19:00 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-29 20:01 receive snapshot, complains about missing file Alexander Fougner
2016-04-29 20:17 ` Chris Murphy
2016-04-29 20:20 ` Alexander Fougner
2016-04-29 20:28 ` Chris Murphy
2016-04-30 10:27 ` Alexander Fougner
2016-04-30 10:28 ` Alexander Fougner
2016-04-30 10:49 ` Duncan
2016-04-30 10:55 ` Alexander Fougner
2016-04-30 11:28 ` Duncan
2016-05-03 19:00 ` Alexander Fougner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).