Unexpected behavior involving file attributes and snapshots.
I was just experimenting with snapshots on 4.9.0, and came across some unexpected behavior.
The simple explanation is that if you snapshot a subvolume, any files in the subvolume that have the NOCOW attribute will not have that attribute in the snapshot. Some further testing indicates that this is the only file attribute that isn't preserved (I checked all the chattr flags that BTRFS supports).
I'm kind of curious whether:
1. This is actually documented somewhere, as it's somewhat unexpected given that everything else is preserved when snapshotting.
2. This is intended behavior, or just happens to be a side effect of the implementation.
Quoted 9 lines · On Tue, 14 Feb 2017 10:30:43 -0500 "Austin S. Hemmelgarn"…
I was just experimenting with snapshots on 4.9.0, and came across some unexpected behavior.
The simple explanation is that if you snapshot a subvolume, any files in the subvolume that have the NOCOW attribute will not have that attribute in the snapshot. Some further testing indicates that this is the only file attribute that isn't preserved (I checked all the chattr flags that BTRFS supports).
Quoted 5 lines
I'm kind of curious whether:
1. This is actually documented somewhere, as it's somewhat unexpected given that everything else is preserved when snapshotting.
2. This is intended behavior, or just happens to be a side effect of the implementation.
I don't seem to get this on 4.4.45 and 4.4.47.
$ btrfs sub create test Create subvolume './test' $ touch test/abc $ chattr +C test/abc $ echo def > test/abc $ ls -la test/abc -rw-r--r-- 1 rm rm 4 Feb 14 20:52 test/abc $ lsattr test/abc ---------------C test/abc $ btrfs sub snap test test2 Create a snapshot of 'test' in './test2' $ ls -la test2/abc -rw-r--r-- 1 rm rm 4 Feb 14 20:52 test2/abc $ lsattr test2/abc ---------------C test2/abc
Signature · 2 lines
With respect, Roman
Quoted 8 lines · Austin S. Hemmelgarn
I was just experimenting with snapshots on 4.9.0, and came across some unexpected behavior.
The simple explanation is that if you snapshot a subvolume, any files in the subvolume that have the NOCOW attribute will not have that attribute in the snapshot. Some further testing indicates that this is the only file attribute that isn't preserved (I checked all the chattr flags that BTRFS supports).
Huh, I can't reproduce this with 4.9.8 or 4.10rc7. systemd sets journal files with chattr +C, and I do manual snapshots of rootfs periodically, and those snapshots have journal files that have +C still set.
Signature · 1 line
Chris Murphy
Quoted 11 lines · Chris Murphy
Quoted 8 lines · Austin S. Hemmelgarn
I was just experimenting with snapshots on 4.9.0, and came across some unexpected behavior.
The simple explanation is that if you snapshot a subvolume, any files in the subvolume that have the NOCOW attribute will not have that attribute in the snapshot. Some further testing indicates that this is the only file attribute that isn't preserved (I checked all the chattr flags that BTRFS supports).
Quoted 5 lines
Huh, I can't reproduce this with 4.9.8 or 4.10rc7. systemd sets journal files with chattr +C, and I do manual snapshots of rootfs periodically, and those snapshots have journal files that have +C still set.
Just tested on a different filesystem, and I'm not seeing it there either, I'll take a closer look at the FS I saw this on and see if I can figure out what's up.
Quoted 15 lines · Austin S. Hemmelgarn
Quoted 14 lines · Chris Murphy
Quoted 11 lines · Austin S. Hemmelgarn
I was just experimenting with snapshots on 4.9.0, and came across some unexpected behavior.
The simple explanation is that if you snapshot a subvolume, any files in the
subvolume that have the NOCOW attribute will not have that attribute in the
snapshot. Some further testing indicates that this is the only file attribute that isn't preserved (I checked all the chattr flags that BTRFS
supports).
Quoted 9 lines
Quoted 5 lines
Huh, I can't reproduce this with 4.9.8 or 4.10rc7. systemd sets journal files with chattr +C, and I do manual snapshots of rootfs periodically, and those snapshots have journal files that have +C still set.
Just tested on a different filesystem, and I'm not seeing it there either, I'll take a closer look at the FS I saw this on and see if I can figure out what's up.
After poking around a bit further, the system crashed, and it looks like there was some memory corruption scattered throughout the kernel from one of the other modules I had loaded (now I get to spend a day or more figuring out which one and reporting that bug). Given the state of the kernel crash dump though, I'm actually somewhat surprised that things weren't misbehaving more spectacularly than this.