what btrf version ?2/3 of my btrfs attempts have ended up eating their data. It still has issues under heavy load in a low free space situation. I'll stick with xfs for the foreseeable future.
Who knows, probably been a year since the last time I tried. At some point it doesn't matter--there's no compelling reason for me to try again for a filesystem that's still unstable (that is, still changing rapidly). Maybe some years after it's settled down I'll look again.what btrf version ?
it is stable for 0 and 1 ....Who knows, probably been a year since the last time I tried. At some point it doesn't matter--there's no compelling reason for me to try again for a filesystem that's still unstable (that is, still changing rapidly). Maybe some years after it's settled down I'll look again.
like I said before, I like using BTRFS and have been using it for the last 2+ years.it is stable for 0 and 1 ....
I am using 0 and 1 on centos 7.X
I am waiting 5 and 6 actually.. planning to move from zol to btrfs that no worry about dkms or broken (easy to fix, just need time) zfs when upgrading to newer kernel version.
my current:
btrfs 0/1 and zol(zfs) raidz1/2/3
Yes, that's why I'm confused that people are talking about it being stable. :-D Look, the btrfs devs haven't exactly developed a reputation for being careful not to lose data. Given my experience (none of which was on systems that actually mattered for anything, fwiw) I'm not going to suddenly assume that's changed based on anecdotal reports. Given that a lot of guidance from the btrfs devs consists of features which are and are not working well (meaning that it's up to the user to make sure they don't actually try to use a function which will eat their data) it's basically more trouble than it's worth: what I really want from a filesystem is the ability to put bits in and then get the same bits back out, while I'm really thinking about other things which should be more important/interesting than the filesystem.A lot has changed in recent kernel releases..
Because most of those changes are directly related to making it more stable. A lot has changed in Windows 10 as well and yet it also appears to be stable.Yes, that's why I'm confused that people are talking about it being stable. :-D
Windows 10 didn't change the filesystem. People are very conservative about their stored data, for good reason. MS had NTFS in production for almost a decade before it was the default for everything, and ReFS is on a similar trajectory.Because most of those changes are directly related to making it more stable. A lot has changed in Windows 10 as well and yet it also appears to be stable.
For a regular desktop with a single drive, why use a boutique filesystem at all? You won't know the difference in the best case, and it will eat your data in the worst case. If you have a sacrificial machine that you're willing to dedicate to the cause, great--but my desktop is running on an image which has been continuously upgraded and migrated for well over a decade and I don't want to start losing data now. You're right that it's essential that people actually use a filesystem before the bugs are shaken out, but it's critical that they go in with their eyes open. Suggesting that a filesystem in that shakeout period is a safe replacement for something with a long track record for stability does a disservice both to users and to fs developers. I also question your assertion that parity raid is a rare beast in the context of a system wherein a boutique filesystem is interesting.BTRFS is now production ready for basic use-cases eg. a regular desktop/laptop with a single drive. Lots of people using it on a daily basis is pretty much required at this point to find the remaining bugs and get them fixed. RAID-0/1/10 across multiple drives is also quite mature and is safe to use although there are still additional features on the roadmap (eg. N-way mirroring if you want more than 2 copies) Parity-raid is not yet ready for production use (and is also not something that an average user even knows what means), but is code-complete now for the minimal features and is ready for public testing.
Which is it that makes this attractive? The minimal stable set of features that (at best) make btrfs pretty much like any other filesystem, or the planned exotic set of features that isn't stable yet? How do I know which ones are safe on any given day?Ya there are a lot of niche filesystems out there that can be fun to play with if you're a storage geek, or that fill a need in some rare use-case. BTRFS happens to have a planned feature-set though that imho will make it the best filesystem available for the majority of at-home uses as well as many enterprise uses. All of the data protection abilities of ZFS combined with the flexibility to use a bunch of drives of varying capacity and also add/remove drives from the volume on the fly would be the ultimate home NAS, just needing a nice UI to make it simple to use (eg. Rockstor). We just need to wait a little bit longer for a few final features to materialize/mature - raid5/6 with the current variable-stripe-width chunk allocation should be mature enough for most of us after a few more kernel releases, likely around 4.4
MS has been adding features to NTFS with almost every OS release, which is common thing for filesystems to do. MS just doesn't advertise it as much. But don't go believing that every line of code in NTFS has 20 years of testing behind it.Windows 10 didn't change the filesystem. People are very conservative about their stored data, for good reason. MS had NTFS in production for almost a decade before it was the default for everything, and ReFS is on a similar trajectory.
Why does it have to be labeled boutique? Is everything except NTFS/FAT boutique? Are ext2/3/4/xfs/zfs boutique? Ext2/3/4 have been the default filesystems of many linux distro's over the years, xfs is now the default for RHEL7 (and clones), ZFS is the default for solaris and some BSDs. Btrfs is the default filesystem for suse and is lined up to replace ext4 as the default in many other distro's as it gets more mature. As to why to use it - because even on a single drive it provides benefits. The checksumming may not be able to repair your data if you only have a single drive but you will at least be certain that your data is safe or not, and duplicated metadata should allow the filesystem to at least mount in the case of corruption and recover at least some of the data. Snapshots are also a very handy feature (that is plenty mature), in some cases also integrating into the system package manager for automated snaps at every package upgrade. I'm now using btrfs for all desktop installs I do, whether it is a new system or just an OS upgrade to an older one.For a regular desktop with a single drive, why use a boutique filesystem at all? You won't know the difference in the best case, and it will eat your data in the worst case.
What I've been "suggesting" is that btrfs is no longer in that shakeout period, only certain features are. I was also only asserting that parity raid is rare in the context of the average desktop user, where virtually all boutique filesystems would also be rare. I don't however consider btrfs to be "boutique", and I do believe that there are many non-technical users out there running linux desktops (mostly ubuntu) that could benefit from some of the already stable features in btrfs.Suggesting that a filesystem in that shakeout period is a safe replacement for something with a long track record for stability does a disservice both to users and to fs developers. I also question your assertion that parity raid is a rare beast in the context of a system wherein a boutique filesystem is interesting.
I will admit that knowing when new features become safe to use is a problem - its not a problem specific to btrfs but affects many open-source projects. It is easier in the closed-source world of expensive software and expensive support contracts - the code may not be any more mature but at least you have a large corporate entity giving you a written guarantee that stuff will work as it should, and a phone number to call when it doesn't. If you want that for btrfs feel free to give oracle a call as they certify/support it for production use.Which is it that makes this attractive? The minimal stable set of features that (at best) make btrfs pretty much like any other filesystem, or the planned exotic set of features that isn't stable yet? How do I know which ones are safe on any given day?
I am getting used to create a partition on the drive. this is my habit since 4 years ago ...like I said before, I like using BTRFS and have been using it for the last 2+ years.
so far I had only one incident leading to loss of data using btrfs raid1 pools.
and I do believe I found a bug when it comes to btrfs and raw devices.
so now I simply prepare my disks beforehand with gdisk or something
create a partition table and a single partition on the disk and use the partition in the pool.
an extra step but nothing we did not have to do before.
mine too now...I am getting used to create a partition on the drive. this is my habit since 4 years ago ...
all my btrfs are running on non raw disk.
I remember that you can use raw disk on mdadm , I think I did before move to btrfs 0/1
I didn't say that every line of code hasn't changed in 20 years. I did suggest that they're not making radical consumer-facing changes. ext4, xfs, zfs all change things also but (unlike btrfs) start with a stable foundation, introduce relatively small and comprehensible changes, and don't generally use the changed code by default until its been used in the wild for a while.MS has been adding features to NTFS with almost every OS release, which is common thing for filesystems to do. MS just doesn't advertise it as much. But don't go believing that every line of code in NTFS has 20 years of testing behind it.
ext2 et al, as well as xfs have been used for years, have a large userbase, are fairly stable, and have a straightforward and well understood set of features and interfaces. So no, not boutique.Why does it have to be labeled boutique? Is everything except NTFS/FAT boutique? Are ext2/3/4/xfs/zfs boutique?
Suse used to default to reiserfs; I won't pretend to understand why they make the decisions they do. It's telling that they tend to stand alone. It's also telling that you seem to keep saying but ignoring the implications of what I consider to be the key part: "they will use this when it gets more mature".Btrfs is the default filesystem for suse and is lined up to replace ext4 as the default in many other distro's as it gets more mature.