This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
So I want to make sure that bitrot protection is enabled on my files, I don't recall if I had it enabled on my shares before files were placed there. According to the documentation you can create a new copy of the file and this will create CoW data for the new file. Does moving a file with the mv command do the same thing, or do you need to use the cp command to create another copy?
I made a new share, mv'd the files between, then removed the old share. Do I need to do this again with cp instead or did mv handle my task?
I don't think the "mv" command is enough to trigger CoW on a file that has previously been marked for No CoW - due to reasons that @StephenB mentioned. I think you need to re-create the file - i.e. "cp"
I made a new share, mv'd the files between, then removed the old share. Do I need to do this again with cp instead or did mv handle my task?
I'm not 100% sure, but I think you'll need to do it again with cp.
If you are moving from window file explorer, the move is turned into a copy/delete when you access the shares using normal credentials. But if you access the full data volume using admin credentials, that doesn't happen - only the metadata is rewritten.
When you mv using ssh on the NAS, it's like that second case. The mv completes much faster than cp will, but that is because the file data isn't being copied. The bitrot protection feature depends on BTRFS checksums (plus RAID parity), and if they were turned off when you uploaded the files to the NAS, a "true" mv won't create them.
In order for bit-rot protection to work, you need both BTRFS checksums and RAID parity. My understanding is that the only safe way to create the BTRFS checksums is to copy the file data itself after checksums are enabled. That won't happen if the files are moved.
There is a linux command that can also recalculate the checksums - but it is considered dangerous. Normally the file system is unmounted before that command is run.
I don't think the "mv" command is enough to trigger CoW on a file that has previously been marked for No CoW - due to reasons that @StephenB mentioned. I think you need to re-create the file - i.e. "cp"
Had a quick Google and interestingly enough, you might be able to change it on the fly, using "chattr". Have look here: https://en.wikipedia.org/wiki/Chattr
I haven't played around with this much though, changing CoW attributes, but I guess it should work 🙂
Confirmed that moved files have the C attribute, thus lacking CoW. Newly copied files are created without the C attribute, thus having CoW. Weird that they display it like this.
For the sake of making sure that CoW is enabled on these I think I should just copy and be done with it, rather than risking issues later if changing the attribute doesn't perform as needed.
