On 2017-04-17 13:36, Chris Murphy wrote:
HI,
/dev/nvme0n1p8 on / type btrfs
(rw,relatime,seclabel,ssd,space_cache,subvolid=258,subvol=/root)
I've got a test folder with +C set and then copied a test file into it.
$ lsattr
----------------C--
./system@2547b430ecdc441c9cf82569eeb22065-0000000000000001-00054c3c31bec567.journal
So now it's inherited +C. Next check fragments and compression.
$ sudo ~/Applications/btrfs-debugfs -f
system@2547b430ecdc441c9cf82569eeb22065-0000000000000001-00054c3c31bec567.journal
(290662 0): ram 100663296 disk 17200840704 disk_size 100663296
file:
system@2547b430ecdc441c9cf82569eeb22065-0000000000000001-00054c3c31bec567.journal
extents 1 disk size 100663296 logical size 100663296 ratio 1.00
Try to compress it.
$ sudo btrfs fi defrag -c
system@2547b430ecdc441c9cf82569eeb22065-0000000000000001-00054c3c31bec567.journal
Check again.
[snip faux fragments]
file:
system@2547b430ecdc441c9cf82569eeb22065-0000000000000001-00054c3c31bec567.journal
extents 768 disk size 21504000 logical size 100663296 ratio 4.68
It's compressed! OK??
OK delete that file, and add +c to the temp folder.
$ lsattr
--------c-------C-- ./temp
Copy another test file into temp.
$ lsattr
--------c-------C--
./system@2547b430ecdc441c9cf82569eeb22065-000000000002eb9f-00054d4ebb44b135.journal
$ sudo ~/Applications/btrfs-debugfs -f
system@2547b430ecdc441c9cf82569eeb22065-000000000002eb9f-00054d4ebb44b135.journal
(290739 0): ram 83886080 disk 21764243456 disk_size 83886080
file:
system@2547b430ecdc441c9cf82569eeb22065-000000000002eb9f-00054d4ebb44b135.journal
extents 1 disk size 83886080 logical size 83886080 ratio 1.00
Not compressed. Hmmm. So somehow btrfs fi defrag -c will force
compression even on nocow files? I've also done this without -c
option, with a Btrfs mounted using compress option; and the file does
compress also. I thought nocow files were always no compress, but it
seems there's exceptions.
This is odd behavior. The fact that it's inconsistent is what worries
me the most though, not that it's possible to compress NOCOW files (the
data loss window on a compressed write is a bit bigger than an
uncompressed one, but it still doesn't have the race conditions that
checksums+NOCOW does).
I'm willing to bet the issue is in how the FS handles defragmentation,
seeing as the only case here where it was compressed was after you
compressed it using the defrag command, which IIRC, doesn't actually do
any checks in the kernel side except making sure nothing has the file
mapped as an executable.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
