‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, 6 May 2019 г., 8:40, Chris Murphy <li...@colorremedies.com> wrote:
> On Sun, May 5, 2019 at 3:09 AM Andrei Borzenkov arvidj...@gmail.com wrote: > > > 05.05.2019 10:50, Maksim Fomin пишет: > > > > > Good day. > > > Since 5.0 btrfs supports swap files. Does it support hibernation into > > > a swap file? > > > With kernel version 5.0.10 (archlinux) and btrfs-progs 4.20.2 > > > (unlikely to be relevant, but still) when I try to hibernate with > > > systemctl or by directly manipulating '/sys/power/resume' and > > > '/sys/power/resume_offset', the kernel logs: > > > PM: Cannot find swap device, try swapon -a PM: Cannot get swap > > > writer > > > > How exactly do you compute resume_offset? What are exact commands you > > ise to initiate hibernation? systemctl will likely not work anyway as > > systemd is using FIEMAP which returns logical offset of file extents in > > btrfs address space, not physical offset on containing device. You will > > need to jump from extent vaddr to device offset manually. > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/power/swsusp-and-swap-files.txt?h=v5.0.13 > > This says the resume_offset= is an "offset, in <PAGE_SIZE> units, > from the beginning of the partition which holds the swap file" > > Use filefrag (uses FIEMAP) to get the virtual address, multiply by > 4KIB to get bytes, and plug that into > > btrfs-map-logical -l vaddrbyte <dev> > > The physical number returned is also in bytes. Normally to get LBA > you'd divide by 512 (for anything other than a 4Kn drive), but if I > understand the kernel document correctly, it needs to be in x86_64 > page size, so divide by 4096 instead. > > > > Chris Murphy Thanks everybody for clarification! After several attempts to create 1-extent file it appears that btrfs can do this only for files around 500-600 MiB which is low for my practical needs. If swap file is increased to 1-1.5 GiB, then there is non-contigous extents problem. In any case, since swap file can be (with high probability) moved across filesystem, then 1) offset configuration cannot be stored (should be reconfigured for each hibernation) and 2) there is risk that kernel writes directly to disk at wrong place and will corrupt the filesystem. I don't like this feature. Best regards, Maksim Fomin
