A Btrfs File-System Kernel Driver For Windows

[erendorn]

Why new and new filesystem formats, its some linux obsession.. What is wrong with EXT4? On Widows we are using more that 15 years ntfs and we are still ok.

Off the top of my head:
- Copy on write
- snapshots (thanks to CoW)
- checksumming
- native raid
- autorepair (checksum + raid)
- send/receive for backup (orders of magnitude faster than rsync)

[Steffo]

I really don't trust BTRFS. I heard too many bad things about it. Ok, the bug, which makes the system unusable when only 10 GB are left on disk seems to be fixed. But still it lacks on integrity when power is suddenly turned off. This filesystem really creeps me and I didn't hear much promissing about it if it is production ready or not in the last 6-12 months. Some company are testing it, but this is it.

[DrYak]

Ok, the bug, which makes the system unusable when only 10 GB are left on disk seems to be fixed.

It's not really a bug, it's due to a very peculiar scheme(*) to allocate block and assign them to different use, that doesn't play very well with small size partitions.

The bug didn't get *fixed*. BTRFS introduced another scheme call "mixed mode", where the FS doesn't use separate block group for data and metadata but used mixed chunk for all, so the "need some space but all free sectors are used in block groups of the wrong type" situation can't happen anymore on small device.

Big devices aren't affected that much.

(*) - For data, BTRFS works in block groups of ~1GiB. This can get very problematic when there are e.g. only 16GiB on the mass storage.
So might end up in weird situation where "df" still reports free space (as in "there are sectors or pages which aren't written to yet"), whereas BTRFS complains not having enough space to write. (because all the free space is spread among block groups already allocated but to the wrong type. i.e.: BTRFS needs to write metadata, all the metadata is full, so it needs to allocate a new block groups of metadata, but there's not more space that isn't assigned on the drive. All the free sectors/pages are inside block groups which are currently assigned for data.
One would need first to rebalance all the data, which will compact the block groups, and free some data block group. Once there's space free, these free sector could be reassigned to metadata block groups.


ALSO NOTE:
remember that BTRFS (like ZFS) are *Copy-on-write* based file system.
Like with log-structured file systems (like UDF or F2FS) that means that you when you're overwriting part of a file, you aren't overwriting the file's sectors on disk.
You are actually writing a new copy of the sectors somewhere else, and then the old copy will get garbage collected - unless it is used by another snapshot (or unless it's a log structured FS, in which case old copy are kept for as long as possible until need-for-freespace pressures pushes them out).
That means, even if you're just modifying file content, you DO need free space (because you'll be writing new copies of modified blocks and not overwriting blocks inside a file).

But still it lacks on integrity when power is suddenly turned off.

Stemming from the CoW approach of BTRFS, it's actually a little bit hard to wrap one head's around the proper procedure to follow in case of power loss or corruption or to why the FSCK function took so long to get developped.

Actually BTRFS is in my experience one of the easiest filesystem to recover from:
Due to CoW, data is never over-written, only new copies written (and then eventually the old copies being garbage colelcted). That means, in case of powerloss or other corruption, recovering the system could be as simple as using an older copy of the data.

In fact, in BTRFS-land, fsck is the last resort when everything else fails.
- you could mount a partition with recovery option (do not fail when finding inconsistencies while mounting)
- you could try mounting an older copy
- recover data from snapshot
or if the kernel definitely can't mount the partition, use various "btrfs recovery" options.


I'm not saying "GO PUT ALL YOUR MOST SENSITIVE DATA ON BTRFS RIGHT NOW !!!!"(*)
but BTRFS is definitely in much better shape than what some people might think.


(*) - If I was as uncomfortable as you, I wouldn't put all my most sensitive data on *one single* btrfs partition right now.
On the other hand, right now, correct use of BTRFS, including its snapshoting properties (so you actually keep a log of several historical copies in a "time-line" fashion) and its send/receive facilities (so you can easily perform incremental copies of said snapshot to another partition in a secure location) is DEFINITELY worth a look.

[DrYak]

Windows BTRFS driver would be a nice idea for sharing access to /home, etc.
(just like the various EXTn and ReiserFS drivers and accessors used to be before it).

BUT

UDF is still my favourite for sharing simple data between OSes (on flashdisk or HD partitions).
- it works out of the box on nearly anything that is able to read a DVD. (Including Linux, Windows and Mac OS X. Including several no-name media playing boxes)
- its log-structued FS (like F2FS) so its gentler toward flash.

[Hi-Angel]

DrYak so, would you recommend using BTRFS on a usb-stick? I wanted to give it a try because it supports transparent compression, but now I'm not sure…

[waxhead]

Why new and new filesystem formats, its some linux obsession.. What is wrong with EXT4? On Widows we are using more that 15 years ntfs and we are still ok.

I think the simple answer to this is: If you can have something better for free, why not?! Ext4 works fine, but lacks features that btrfs has. Btrfs if also a different concept that some would argue is butter... better. As for NTFS. It is a OK filesystem that works most of the time, I have not had any catastrophic failures on NTFS, but at the same time I have had more "minor-weird behavior" (undeleteable files, dataloss, corruption etc...) on NTFS than any other filesystem I have ever used including Amiga's FFS and OFS as well as the filesystem used on Commodore 64 floppies

[DrYak]

DrYak so, would you recommend using BTRFS on a usb-stick? I wanted to give it a try because it supports transparent compression, but now I'm not sure…

As an experiment? Sure, why not...

As a storage of more sensitive data? Depends.

It has some advantages:
- BTRFS send/receive: means that you can easily implement an incremental backup strategy. (But which comes for free given the BTRFS' easy snapshotting. Instead of requiring CPU cycles like rsync checksumming the hell out of everything prior to starting sending bytes) -- I think that's the main reason to try BTRFS.
- CoW will cause less overwriting which can help wear-leveling, even without the flash' firmware supporting static levelling. (Like UDF, unlike other more conventionnal FS).
- checksumming (so you can easily detect when data is corrupted).
- for some workload, transparent compression can help.

It also has disadvantages:
- will perform poorly with small-sized medium (which is often the case with USB sticks) unless formatted for mixed mode block groups
- not universally supported (which is a problem for an exchange medium like USB-flash)
- less maturity than other filesystems

I would recommend trying UDF for usb-sticks.

[pipe13]

There's a lengthy discussion thread r.e. UDF vs FAT32 on usb sticks designed and optimized for FAT32. Yes, UDF can be formatted on them.(IIRC I've ext3 on one several years ago). And UDF has POSIX permissions, including a "nobody" for inter-os interoperability. Whether it will wear-level better than FAT32 for many re-writes of small files is a matter of debate. See http://tanguy.ortolo.eu/blog/article93/usb-udf

UDF does not appear suitable for HDD or SDD -- not robust enough for OS usage.

[Hi-Angel]

There's a lengthy discussion thread r.e. UDF vs FAT32 on usb sticks designed and optimized for FAT32. Yes, UDF can be formatted on them.(IIRC I've ext3 on one several years ago). And UDF has POSIX permissions, including a "nobody" for inter-os interoperability. Whether it will wear-level better than FAT32 for many re-writes of small files is a matter of debate. See http://tanguy.ortolo.eu/blog/article93/usb-udf

UDF does not appear suitable for HDD or SDD -- not robust enough for OS usage.

No. What you're talking about is so called «erase block size» (I just recently were mucking around with this, so I know a little). So, a just bought usb-stick is usually formatted in such a way so that block size would be the size of the «erase block size» (EBS), and the start of the partition is fixed accordingly to match the EBS. Afterwards, if one is reformatting the stick even with FAT, there's possibility to miss that EBS, and since that moment that doesn't even matter what filesystem there is.

Finding EBS is possible with some heuristic e.g. with flashbench. Thus, one could format a usb-stick with any file system, and have low wear-level and faster IO by just making block size while formatting of EBS size.

From what I found, there could be a problem though (WinXP only?) that if you set block size different of 512b for UDF filesystem, some Windows versions could didn't recognize it.

[Ericg]

I really don't trust BTRFS. I heard too many bad things about it. Ok, the bug, which makes the system unusable when only 10 GB are left on disk seems to be fixed. But still it lacks on integrity when power is suddenly turned off. This filesystem really creeps me and I didn't hear much promissing about it if it is production ready or not in the last 6-12 months. Some company are testing it, but this is it.

Eh? That was really my reaction when i read your comment, not because it was a bad comment, but just because you didn't necessarily make an explicit point or argument. Anecdotal evidence: I've got a laptop running Btrfs Raid0 across 2 SSD's of different sizes ontop of LUKS with transparent compression turned on. I've had kernel oops, I've had deadlocked, I've had "I disallowed hibernation and the battery died", I've had "fuck it, just hold the power button in", and Btrfs has continued to chugalong just fine. The entire filesystem is designed around the idea of "you shouldn't lost data." Now, yes, its still relatively young (compared to ZFS, or ext_), so there are still bugs. But the over all design is that randomly losing power should NOT corrupt data.

You did make reference to one problem with Btrfs, which has been partially fixed. It -really- doesn't like it when its backing disks are getting low on space.

As far as whether its production ready.. ask Facebook and OpenSuse, they'd know. I am VERY close to making Btrfs the default filesystem on every Linux disk I have, EXCEPT for the absolute mission critical ones. Those are getting Raid1 Ext4. The stuff where I can't lose the data on those drives AND the copies on those drives are the ONLY copies I have.

No one here can tell if you if its ready for you. Go. Go play with it on a test machine. See if you like it, see if it works for you. If it does, great, congrats. If not, stick with ext4 / xfs / ZFS.