Linux swap file not activating after reboot

Linux swap file not activating after reboot

[Michael Ruiz]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

Hi,
 I have a //@swap subvolume and i have a swapfile within it. I mount the 
subvolume like such in fstab:

`rw,ssd,nofail,noautodefrag,nodatacow,nodatasum,subvolid=1234,subvol=/@swap`

It mounts correctly, but 1/15/20 4:20 PM kernel I get: 

`BTRFS warning (device dm-0): swapfile must not be copy-on-write`

I did chattr +C on the empty swapfile as per arch wiki instructions. The only 
problem is that it does not work after reboot... Does btrfs allow subvolumes 
to have different mount options?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Linux swap file not activating after reboot

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 726 bytes --]



On 2020/1/16 上午8:34, Michael Ruiz wrote:
> Hi,
>  I have a //@swap subvolume and i have a swapfile within it. I mount the 
> subvolume like such in fstab:
> 
> `rw,ssd,nofail,noautodefrag,nodatacow,nodatasum,subvolid=1234,subvol=/@swap`
> 
> It mounts correctly, but 1/15/20 4:20 PM kernel I get: 
> 
> `BTRFS warning (device dm-0): swapfile must not be copy-on-write`
> 
> I did chattr +C on the empty swapfile as per arch wiki instructions. The only 
> problem is that it does not work after reboot... Does btrfs allow subvolumes 
> to have different mount options?

If that file has nodatacow, then it may be possible that you had a
snapshot of that subvolume, and caused problem.

Thanks,
Qu


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Linux swap file not activating after reboot

[David Sterba]

On Wed, Jan 15, 2020 at 04:34:02PM -0800, Michael Ruiz wrote:
> Hi,
>  I have a //@swap subvolume and i have a swapfile within it. I mount the 
> subvolume like such in fstab:
> 
> `rw,ssd,nofail,noautodefrag,nodatacow,nodatasum,subvolid=1234,subvol=/@swap`
> 
> It mounts correctly, but 1/15/20 4:20 PM kernel I get: 
> 
> `BTRFS warning (device dm-0): swapfile must not be copy-on-write`

There are two reasons why the message is printed, one is when the file
does not have the C attribute and another one when the the existing file
extents need to be COWed (same case as if the file is NOCOW and has been
snapshotted).

Plain reboot will not change the C attribute, so either there's a
snapshot of /@snap or the check of a used swapfile is wrong.

I tested it here, a swapfile that got almost full after a stress test,
followed by reboot and swapon (without any change to the file) was ok.

Doing a snapshot and swapon resulted in the message you saw.

After deleting the snapshot and waiting until it gets cleaned, swapon
did not activate the file anymore. Filefrag or fiemap don't report any
shared extents so here I' expect that the file should be in a valid
state for swapon.

Omar, any ideas?

Re: Linux swap file not activating after reboot

[Omar Sandoval]

On Thu, Jan 16, 2020 at 07:55:39PM +0100, David Sterba wrote:
> On Wed, Jan 15, 2020 at 04:34:02PM -0800, Michael Ruiz wrote:
> > Hi,
> >  I have a //@swap subvolume and i have a swapfile within it. I mount the 
> > subvolume like such in fstab:
> > 
> > `rw,ssd,nofail,noautodefrag,nodatacow,nodatasum,subvolid=1234,subvol=/@swap`
> > 
> > It mounts correctly, but 1/15/20 4:20 PM kernel I get: 
> > 
> > `BTRFS warning (device dm-0): swapfile must not be copy-on-write`
> 
> There are two reasons why the message is printed, one is when the file
> does not have the C attribute and another one when the the existing file
> extents need to be COWed (same case as if the file is NOCOW and has been
> snapshotted).
> 
> Plain reboot will not change the C attribute, so either there's a
> snapshot of /@snap or the check of a used swapfile is wrong.
> 
> I tested it here, a swapfile that got almost full after a stress test,
> followed by reboot and swapon (without any change to the file) was ok.
> 
> Doing a snapshot and swapon resulted in the message you saw.
> 
> After deleting the snapshot and waiting until it gets cleaned, swapon
> did not activate the file anymore. Filefrag or fiemap don't report any
> shared extents so here I' expect that the file should be in a valid
> state for swapon.
> 
> Omar, any ideas?

Hm, we're hitting this check in can_nocow_extent():

        if (btrfs_file_extent_generation(leaf, fi) <=
            btrfs_root_last_snapshot(&root->root_item))

That check was added in 78d4295b1eee ("btrfs: lift some
btrfs_cross_ref_exist checks in nocow path") as an optimization. Even if
we comment that out, we'll hit the similar check in
btrfs_cross_ref_exist():

        /* If extent created before last snapshot => it's definitely shared */
        if (btrfs_extent_generation(leaf, ei) <=
            btrfs_root_last_snapshot(&root->root_item))

That's not quite right in exactly this case that the snapshot has been
deleted. Apparently we've been doing unnecessary COW for this case. I'll
need to think about how to safely avoid these checks without too much of
a performance hit.

Thanks for the report!

Re: Linux swap file not activating after reboot

[Michael Ruiz]

[-- Attachment #1: Type: text/plain, Size: 3380 bytes --]

On Thursday, January 16, 2020 12:43:29 PM PST you wrote:
> On Thu, Jan 16, 2020 at 07:55:39PM +0100, David Sterba wrote:
> > On Wed, Jan 15, 2020 at 04:34:02PM -0800, Michael Ruiz wrote:
> > > Hi,
> > > 
> > >  I have a //@swap subvolume and i have a swapfile within it. I mount the
> > > 
> > > subvolume like such in fstab:
> > > 
> > > `rw,ssd,nofail,noautodefrag,nodatacow,nodatasum,subvolid=1234,subvol=/@s
> > > wap`
> > > 
> > > It mounts correctly, but 1/15/20 4:20 PM kernel I get:
> > > 
> > > `BTRFS warning (device dm-0): swapfile must not be copy-on-write`
> > 
> > There are two reasons why the message is printed, one is when the file
> > does not have the C attribute and another one when the the existing file
> > extents need to be COWed (same case as if the file is NOCOW and has been
> > snapshotted).
> > 
> > Plain reboot will not change the C attribute, so either there's a
> > snapshot of /@snap or the check of a used swapfile is wrong.
> > 
> > I tested it here, a swapfile that got almost full after a stress test,
> > followed by reboot and swapon (without any change to the file) was ok.
> > 
> > Doing a snapshot and swapon resulted in the message you saw.
> > 
> > After deleting the snapshot and waiting until it gets cleaned, swapon
> > did not activate the file anymore. Filefrag or fiemap don't report any
> > shared extents so here I' expect that the file should be in a valid
> > state for swapon.
> > 
> > Omar, any ideas?
> 
> Hm, we're hitting this check in can_nocow_extent():
> 
>         if (btrfs_file_extent_generation(leaf, fi) <=
>             btrfs_root_last_snapshot(&root->root_item))
> 
> That check was added in 78d4295b1eee ("btrfs: lift some
> btrfs_cross_ref_exist checks in nocow path") as an optimization. Even if
> we comment that out, we'll hit the similar check in
> btrfs_cross_ref_exist():
> 
>         /* If extent created before last snapshot => it's definitely shared
> */ if (btrfs_extent_generation(leaf, ei) <=
>             btrfs_root_last_snapshot(&root->root_item))
> 
> That's not quite right in exactly this case that the snapshot has been
> deleted. Apparently we've been doing unnecessary COW for this case. I'll
> need to think about how to safely avoid these checks without too much of
> a performance hit.
> 
> Thanks for the report!

My solution was to boot into an arch live usb, unlock my dmcrypt partition and 
mount the btrfs partition to /mnt. After that I created a subvolume on the @ 
directory (top level 5) instead of a subvolume of my root (/) partition. 
So now my subvolume layout is like this:

ID 256 gen 45343 top level 5 path @
ID 257 gen 45346 top level 5 path @home
ID 258 gen 45346 top level 5 path @log
ID 259 gen 44303 top level 5 path @srv
ID 260 gen 44650 top level 5 path @pkg
ID 261 gen 45346 top level 5 path @tmp
ID 1607 gen 43963 top level 5 path @swap

The strange thing to me is that I didn't ask for snapshots of this subvolume, 
although I do keep snapshots of my / directory, I was under the impression 
that snapshots would not be recursive and go into the /swap subvolume. I can 
also confirm I had the +C attribute while getting this error. So now I am able 
to mount this subvolume with it's own options, whereas before I guess it 
inherited options from the root dir which has CoW enabled. The problem is now 
resolved by doing this. Thanks for the responses.




[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Linux swap file not activating after reboot

[David Sterba]

On Thu, Jan 16, 2020 at 04:44:18PM -0800, Michael Ruiz wrote:
> My solution was to boot into an arch live usb, unlock my dmcrypt partition and 
> mount the btrfs partition to /mnt. After that I created a subvolume on the @ 
> directory (top level 5) instead of a subvolume of my root (/) partition. 
> So now my subvolume layout is like this:
> 
> ID 256 gen 45343 top level 5 path @
> ID 257 gen 45346 top level 5 path @home
> ID 258 gen 45346 top level 5 path @log
> ID 259 gen 44303 top level 5 path @srv
> ID 260 gen 44650 top level 5 path @pkg
> ID 261 gen 45346 top level 5 path @tmp
> ID 1607 gen 43963 top level 5 path @swap
> 
> The strange thing to me is that I didn't ask for snapshots of this subvolume, 
> although I do keep snapshots of my / directory, I was under the impression 
> that snapshots would not be recursive and go into the /swap subvolume.

No, snapshots are not recursive.

> I can 
> also confirm I had the +C attribute while getting this error. So now I am able 
> to mount this subvolume with it's own options, whereas before I guess it 
> inherited options from the root dir which has CoW enabled. The problem is now 
> resolved by doing this. Thanks for the responses.

The file attribute has precedence over the mount options, so it should
not matter if you had nodatacow or not when creating the file (assuming
you set the +C flag manually).