On 2021/7/16 下午9:15, Dave T wrote:

On Thu, Jul 15, 2021 at 9:05 PM Qu Wenruo [off-list ref] wrote:

quoted

quoted

I've been running arch + btrfs since 2014. I keep arch linux fully
updated. I'm running new kernels and new btrfs progs. However, I
created this filesystem around 2014.

The change that don't allow allow compression if the inode has NODATASUM
option is introduced in commit 42c16da6d684 ("btrfs: inode: Don't
compress if NODATASUM or NODATACOW set"), which is from v5.2 in 2019.

Thus such old fs indeed can be affected.

quoted

Is there an option to "update" my BTRFS filesystem? Is that even a thing?

I don't think so, but please allow me to do more testing and then I may
craft a fix in btrfs-progs to allow btrfs-check to repair such problems.

I hope that there is soon a way to run a btrfs-progs command to update
an old filesystem to the current standards.
Where can I send you a small donation to express my support for
something like this?

No need, we're a open community and I have a day job (working on btrfs).

quoted

If possible I would enhance kernel to handle such existing file extents
better so that what you really need is just run "pacman -Syu" as usual,
nothing to bother.

This would indeed be a fantastic solution!

quoted

So I'm afraid there is something different involved for your read error problem.

I am less worried about this specific problem than about the general
problem of having an old filesystem on a fully updated rolling release
linux system. I was able to restore all my data to a new SSD and I am
just testing this old SSD to give you feedback.

However, I do have some general questions. As it stands currently,
what exactly is an "old filesystem"? If I run "mkfs.btrfs" with linux
kernel v5.1, is all data in that filesystem somehow affected even
after I install newer kernels?

It's not about the mkfs, but the data write using older kernels.

You can even have mkfs from v5.12, then mount with v5.1, and write some
data, then you may have the file extents described above.

Or are files created when running the
newer kernel not affected? What about files copied?

If using newer kernel, btrfs won't create any compressed extents if the
inode has NODATASUM flag.

So your "files created when running the newer kernel not affected" part
is correct.

File copied counts as the same.

If I do a btrfs send|receive from a fs originally created in 2014 but
now I am running the latest arch linux kernel, what is the result?

Btrfs receive is just doing the file writes in user space.

Then the newer kernel will follow its new behavior, so received files
are all fine.

Do
my transferred files still have hallmarks of the 2014 filesystem they
originally lived on?

Nope.

Are there some checks I should do now on my other devices with btrfs
filessystems originally created around 2014? (I have a lot of such
devices because in 2014 I decided to run arch linux and btrfs
everywhere.)

No need at least for the compressed file extents with NODATASUM inode
problem.

Kernel is able read it without problem.

Thus that's why I can't reproduce your original problem.

quoted

When the read error happens, is there really no extra kernel error message?

I can do more testing and let you know. Can you suggest any tests you
would like me to try?

1. Try to read the affected file:

- Mount the btrfs

- Read inode 262 in root 329 (just one example)
   You can use "find -inum 262" inside root 329 to locate the file.

   If you have a file you know you can't read, that would be the best
   case, just try to read that.

- Unmount the btrfs

- Attached the full dmesg.


2. Reproduce the Read-only fs problem.

- Find a way to reproduce the read-only fs problem
   If you don't have a reliable way to reproduce it, just ignore this
   part.

- Attach the full dmesg

Thanks,
Qu

I could run "journalctl -f" in one window and do
some file operations in another program, for example. But I am not a
developer, so there may be limits on what I can do.

Thank you.
Dave