| View previous topic :: View next topic |
| Author |
Message |
krotuss
Apprentice
Joined: 01 Aug 2008
Posts: 245
|
 Posted: Thu Oct 17, 2024 6:23 pm Post subject: Could I mess up my btrfs? |
 |
|
Hi,
I have pulled one drive from my desktop and connected it to rpi5 to test performance.
At first I got obscure error:
| Code: |
[ 174.953922] BTRFS warning (device dm-0): v1 space cache is not supported for page size 16384 with sectorsize 4096
[ 174.954154] BTRFS error (device dm-0): open_ctree failed
|
googling returned mostly cases of corrupted fs, and it took me a while to connect those two together. So after some trial and error I had tried with nospace_cache option and succeeded:
| Code: |
BTRFS warning (device dm-0): read-write for sector size 4096 with page size 16384 is experimental
|
Now I am little worried, I have not done any writes to it, but maybe OS did. Wasn't it customary to require some option to enable experimental, and potentially unsafe, features? On top of that, fs now mounts even without nospace_cache option, so something was probably written. I am curious about what happened to that v1 cache Was it erased, or fs just remembers that it is disabled? From this I have not understood that nospace_chache is persistent.
| Code: | | The v1 space cache can be disabled at mount time with nospace_cache without clearing. |
|
|
| Back to top |
|
 |
krotuss
Apprentice
Joined: 01 Aug 2008
Posts: 245
|
| Posted: Sat Oct 19, 2024 8:43 pm Post subject: |
|
|
Warning is also reported when I mount with -oro:
| Code: | BTRFS warning (device dm-0): read-write for sector size 4096 with page size 16384 is experimental
|
What I find confusing is if it means read-write as opposed to read-only, and is therefore superfluous, or that both reading and writing is experimental. |
|
| Back to top |
|
|
krotuss
Apprentice
Joined: 01 Aug 2008
Posts: 245
|
| Posted: Sat Oct 19, 2024 9:08 pm Post subject: |
|
|
I have attempted to run scrub, this is what happened:
| Code: | btrfs scrub start /mnt/drive9/
scrub started on /mnt/drive9/, fsid *redacted* (pid=31540)
Starting scrub on devid 1
btrfs scrub status /mnt/drive9/
UUID: *redacted*
Scrub started: *redacted*
Status: aborted
Duration: 0:00:00
Total to scrub: 3.60TiB
Rate: 0.00B/s
Error summary: no errors found
|
There is nothing in dmesg. Is there a way how can I find out why it was immediately aborted? Maybe it has to be mounted rw, maybe not. The point is that I don't know. |
|
| Back to top |
|
|
krotuss
Apprentice
Joined: 01 Aug 2008
Posts: 245
|
| Posted: Mon Oct 21, 2024 6:08 pm Post subject: |
|
|
btrfs scrub start, by default does not run on read only filesystem. This epiphany was bestowed upon me once I have used -B option, this causes scrub to run in foreground and as a side effect reveal the truth:
| Code: | btrfs scrub start -B /mnt/drive9/
Starting scrub on devid 1
ERROR: scrubbing /mnt/drive9/ failed for device id 1: ret=-1, errno=30 (Read-only file system)
scrub canceled for *redacted*
Scrub started: *redacted*
Status: aborted
Duration: 0:00:00
Total to scrub: 0.00B
Rate: 0.00B/s
Error summary: no errors found |
Without -B there is no error in dmesg, nor in btrfs scrub status.
Manual page, which I admit I didn't read beforehand, is quite subtle about this:
| Code: | Scrub can be started only on a mounted filesystem, though it's possible to scrub only a selected device. See btrfs scrub start for more.
...
-r run in read-only mode, do not attempt to correct anything, can be run on a read-only filesystem |
So mounting filesystem read write with experimental feature, which can potentially lead to loss of data, is done silently without bothering the user, but running scrub on read only filesystem, which can at most lead to loss of time, requires explicit -r switch. |
|
| Back to top |
|
|
paluszak
Apprentice
Joined: 28 Jun 2004
Posts: 266
Location: Warsaw, Poland
|
|
| Back to top |
|
|
ElDavo
n00b
Joined: 23 Aug 2015
Posts: 19
|
| Posted: Sat Nov 23, 2024 10:15 am Post subject: |
|
|
RPi 5 and Apple Silicon Macs use 16k page sizes (search in wikipedia for page computer memory) (I also tested with 64k  ), while almost all other machines in the world use 4k page size.
We expect 16k page size usage to go mainstream in the following years - for example, Android is adding support for it.
This, however generates some incompatibility problems with some software and also with BTRFS.
As written here https://btrfs.readthedocs.io/en/latest/mkfs.btrfs.html , in btrfs-progs < 6.7 , the sectorsize was matching the host CPU page size.
This means that if you mkfs.btrfs on a Pi with old btrfs-progs, a file system with 16k sectorsize will be created.
BTRFS doesn't support file system with sectorsize > page size: this file system would be unmountable on a x86 PC.
For this reason, they changed the defaults in btrfs-progs 6.7 and the sectorsize is always 4k.
Anyway, what you did was to create a file system in your x86 PC, which defaulted to 4k sectorsize, and then mounted it on the Pi5, which has 16k page sizes.
BTRFS partially supports sectorsize < page size.
As beautifully explained in this emails from April 2024: https://lore.kernel.org/linux-btrfs/fe43cdf8-69ba-48c7-9b84-b5464828747d@gmx.com/T/
The warning still exists because some feature still aren't working / stable:
1. Zoned support: We don't care, it's a datacenter thing
2. Imperfect compression support: Sometimes the data will not be compressed
3. No inline support: Basically, instead of embedding small files inside the metadata blocks directly, they are stored regularly, leading to a waste / less efficient usage of space.
So as you can guess there is nothing critical, we can use our file systems as usual. Actually, since now it's November 2024, these emails are a bit outdated and maybe the feature described aboved are implemented.
Is it less efficient to have sectorsize < page size? Yes, but cross-machine compatibility is much more important. You would have to emulate an ARM machine with qemu to read the FS.
Do you really want the warning to go away? Use a 4k page size kernel. On raspberry pi os you select kernel=kernel8.img instead of kernel=kernel_2712.img , no idea on gentoo. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
