5 ms·

how do you handle btrfs updates? from what I understand it seems like every kernel update I have supports a newer version. are you updating the filesystem regu

how do you handle btrfs updates? from what I understand it seems like every kernel update I have supports a newer version. are you updating the filesystem regularly? does it matter?

rogerbinns 14y ago
I use Ubuntu on all my machines and use the standard kernel that comes with it. For a brief while I used kernel 3.4 on my laptop due to Ivy Bridge issues but could also boot into the Ubuntu 3.2 kernel just fine. (And on the laptop I'm also using encryption.) Note that the kernel has updates of the code, not updates of the filesystem format. Supposedly the last filesystem format change was in 2.6.31 (from 2009). Compression is a format "difference". For example lzo was added about 18 months ago, so in theory an older kernel won't understand your filesystem that is using it. There was some talk about snappy being added earlier this year, but I don't know if it ever was. I haven't encountered any compatibility issues at all with btrfs. In various places I am using compression, RAID 0, RAID 1, ext4 to btrfs conversion, encryption (dmcrypt/LUKS), SATA, USB and who knows what I have forgotten. Except for one system all are on UPS and in general do not experience unclean shutdowns or similar adversity. The only trouble I have ever had is when a filesystem filled up. It gets quite challenging freeing up disk space because deleting a file requires an append to the btree which needs space. btrfs has been an absolute joy for me. I can just throw devices at it. I can do scrubbing without taking systems offline. I could convert existing filesystems. I don't have to perform system administration with it. And I know it will tell me about bitrot. And worst case I have backups, and backups of backups, on and offsite.
- mercurial 14y ago
  What kind of performance do you get out of it? My understanding was that it's still slow compared to, eg, ext4, but it might not be very visible to normal users.
  - rogerbinns 14y ago
    Two things are slow. One is random rewriting of large file contents like a database does. It isn't that bad, but you wouldn't want to run something like MongoDB on btrfs, although I did so for a while. You may see similar issues with virtualization disk images, although that will depend on how much writing you do. I still do this, but don't do much writing and performance is acceptable. The other part is fsync calls. Doing a package install on Debian/Ubuntu is an absolute blizzard of fsync calls, several per file. Kernel 3.5 is better than 3.2 and supposedly 3.7 will be even better again. There is also the 'eatmydata' LD_PRELOAD wrapper which nulls out the fsync calls. It was worthwhile using on 3.2, and with 3.5 I don't bother. That is write issues. I have no noticeable difference in read speeds, and they are limited to the speed of the underlying media, which is pretty much the case for any filesystem. In theory using compression will help for compressible files.
    - mercurial 14y ago
      Thanks for the detailed feedback, much appreciated.

how do you handle btrfs updates? from what I understand it seems like every kernel update I have supports a newer version. are you updating the filesystem regularly? does it matter?

rogerbinns 14y ago

I use Ubuntu on all my machines and use the standard kernel that comes with it. For a brief while I used kernel 3.4 on my laptop due to Ivy Bridge issues but could also boot into the Ubuntu 3.2 kernel just fine. (And on the laptop I'm also using encryption.) Note that the kernel has updates of the code, not updates of the filesystem format. Supposedly the last filesystem format change was in 2.6.31 (from 2009). Compression is a format "difference". For example lzo was added about 18 months ago, so in theory an older kernel won't understand your filesystem that is using it. There was some talk about snappy being added earlier this year, but I don't know if it ever was. I haven't encountered any compatibility issues at all with btrfs. In various places I am using compression, RAID 0, RAID 1, ext4 to btrfs conversion, encryption (dmcrypt/LUKS), SATA, USB and who knows what I have forgotten. Except for one system all are on UPS and in general do not experience unclean shutdowns or similar adversity. The only trouble I have ever had is when a filesystem filled up. It gets quite challenging freeing up disk space because deleting a file requires an append to the btree which needs space. btrfs has been an absolute joy for me. I can just throw devices at it. I can do scrubbing without taking systems offline. I could convert existing filesystems. I don't have to perform system administration with it. And I know it will tell me about bitrot. And worst case I have backups, and backups of backups, on and offsite.

mercurial 14y ago
What kind of performance do you get out of it? My understanding was that it's still slow compared to, eg, ext4, but it might not be very visible to normal users.
- rogerbinns 14y ago
  Two things are slow. One is random rewriting of large file contents like a database does. It isn't that bad, but you wouldn't want to run something like MongoDB on btrfs, although I did so for a while. You may see similar issues with virtualization disk images, although that will depend on how much writing you do. I still do this, but don't do much writing and performance is acceptable. The other part is fsync calls. Doing a package install on Debian/Ubuntu is an absolute blizzard of fsync calls, several per file. Kernel 3.5 is better than 3.2 and supposedly 3.7 will be even better again. There is also the 'eatmydata' LD_PRELOAD wrapper which nulls out the fsync calls. It was worthwhile using on 3.2, and with 3.5 I don't bother. That is write issues. I have no noticeable difference in read speeds, and they are limited to the speed of the underlying media, which is pretty much the case for any filesystem. In theory using compression will help for compressible files.
  - mercurial 14y ago
    Thanks for the detailed feedback, much appreciated.