Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs

[0xBADCODE]

Actually the community flavour is fragmented into several sub-flavours. For example Linux ZFS is incompatible with other implementations if you enable SA xattrs, which is basically a requirement if you plan to use xattrs (or anything that relies on them, like ACLs...) at all.

So, UFS story doomed to repeat itself another time - now same would happen to ZFS. You can't just use "UFS" - there is about half dozen of different flavours, incompatible each other. So if BSD fans about to mumble something about "forks", it looks really funny. Nearly all BSDs are incompatible, far more incompatible than different Linux distros. And then they mumble about forks? That's what I call double standards.

Honestly I don't get these anti-GPL rants. It's not like the GPL takes away anything from anyone in the FOSS world, it just prevents unnecessary forking and fragmentation. It seems the BSD folks are really keen to give Apple and MS a free ride on their work for nothing. Well if that makes them happy...

I do think some proprietary nuts are seriously unhappy that opensource can kick the butt and it is really impossible to take GPLed things away from us and close them, turning into proprietary crap and revoking our rights to change code and learn how it works. You see... greedy corporations revoked Stallman's rights to change code he uses. His payback was more than cool: he invented self-spreading, infection-like algo which overrides weaker (permissive) licenses and uses really uncommon method to spread. It was crafted in ways it just unable to lose. And it worked. I think Stallman should be called one of greatest lifehackers of all times. While GPL can sound scary, it only harmful for those who wants to be e-parasite. It does not hurts those who are up for fair collaboration on equal terms. It only screws those who are not going to contribute. That's what happens if you annoy smard people :-). For me it took about 10 years of thinking and taking part in proprietary software development to understand it's not just a prank and bunch of lunatics but rather carefully planned powerful "terraforming" process which reshaped whole ecosystem in way it makes it inconvenient to be parasite. But I'm happy I was able to understand how it performs :P. At the end of day I think e-parasites deserve their fates. Time to eat some self-spreading e-DDT

[jake_lesser]

I only a few years time, BTRFS will be on every Hard Drive and no one will know what you are talking about if you ask them what ZFS is.

[drSeehas]

I only a few years time, BTRFS will be on every Hard Drive ...

The Btrfs license is compatible with Microsoft Windows and Apple MacOS?
Or do you honestly think, in only a few years time, there will be no longer Windows and MacOS?

[Stellarwind]

I only a few years time, BTRFS will be on every Hard Drive and no one will know what you are talking about if you ask them what ZFS is.

I hear that for years already and yet there is zfs on my hard drives still, which never caused me any issues since very early days of zfs on linux project.

[0xBADCODE]

The Btrfs license is compatible with Microsoft Windows and Apple MacOS?
Or do you honestly think, in only a few years time, there will be no longer Windows and MacOS?

Windows and MacOS X are permitting to have very restrictive EULAs in software, far more restrictive than any GPL and somesuch. So there shouldn't be issues with 3rd party drivers, etc. Say, there is ext2fsd which is GPL-licensed and it mounts EXT4 under Windows. It here and it works. Worse than original driver, but at least you can read/write ext4 drives under windows if you need it.

However, btrfs is generally meant to be multi-disk scalable filesystem and it does not performs very well on small storages below dozen and half gigz. So it likely to be internal filesystem for storages rather than filesystem you use to exchange data between systems. Granted this fact it is just not really important if MacOS or windows can read it. It will be Linux local competitive advantage if they can't. Funny thing is that MS own tactics stabs them in their back :-)

[jacob]

However, btrfs is generally meant to be multi-disk scalable filesystem and it does not performs very well on small storages below dozen and half gigz. So it likely to be internal filesystem for storages rather than filesystem you use to exchange data between systems. Granted this fact it is just not really important if MacOS or windows can read it. It will be Linux local competitive advantage if they can't. Funny thing is that MS own tactics stabs them in their back :-)

MS is developing RTFS whose design and planned features ressemble those of BTRFS. However in its present form (Windows 2012) it is nowhere near being stable or feature complete and I have no idea how it stands in terms of performance.

[drSeehas]

... So there shouldn't be issues with 3rd party drivers, etc. ...

As you can read in my post you replied to, I questioned the following statement:

I only a few years time, BTRFS will be on every Hard Drive ...

If Btrfs will be on every hard drive (including SSDs), the standard file system in Windows and MacOS (market share) has to be Btrfs! No 3rd party driver.

Now you get my point?

[Blue Thunder]

MS is developing RTFS whose design and planned features ressemble those of BTRFS. However in its present form (Windows 2012) it is nowhere near being stable or feature complete and I have no idea how it stands in terms of performance.

RTFS? Do you mean Microsoft's Resilient File System (ReFS): https://en.wikipedia.org/wiki/ReFS

[jacob]

RTFS? Do you mean Microsoft's Resilient File System (ReFS): https://en.wikipedia.org/wiki/ReFS

Yes, of course, ReFS. Sorry.

[0xBADCODE]

MS is developing RTFS whose design and planned features ressemble those of BTRFS. However in its present form (Windows 2012) it is nowhere near being stable or feature complete and I have no idea how it stands in terms of performance.

I know about it. But...
1) Its server-only. OTOH I do not see why decent CoW with snapshots is bad for desktops. Just imagine: you've deleted directory with photos by mistake. Or, even worse, overwrote valuable file with another one and it turned out to be NOT what you wanted. Revert to snapshot (or just mount snapshot) - and woo-hoo, data are back! Sure, this implies some overhead for storage of temporary and especially persistent snapshots and differences. However if your disk space allows it, it could be nice idea to use multiple states/views and it comes at cheap price since general idea that only changed data are stored separately while matching blocks are reused (can be further improved via dedup techniques). Should you screw something up, there could be relatively simple "undo" and it does not implies bug performance penalty since that's how CoW works on its own. CoW does not destroys data immediately in most cases, that's what allows to have multiple states.

2) ReFS features set seems to be really narrow. There are many CoW-like designs around these days. Ok, MS finally got idea their NTFS disk techs from 90s are outdated "a bit", so it's no longer "New Technology" at all . But I do not see any exciting features. And it appeared quickly, so it can happen its internal design haves some silly shortcomings which are hard to undo at later stages, when filesystem is deployed. You see, wide set of features in Btrfs has been planned from begin. And many thinge were taken into account at design phase. So, btrfs can move away data from particular drive to make it unused and remove from pool. This needs back references stored to do it fast and easy. And it would be much better if you create them as you write data, it is hard to do it sometimes later. Then brtfs can enable things like CoW per file and even assumes RAID is block level thing but rather object level, so you can have different RAID levels for different objects. While it is not fully implemented yet (theoretically, you can specify RAID level per file), it still already offers interesting options like storing data and metadata using different RAID levels. And technically underlying design can deal with per-file RAID levels. Needless to say, such things should be taken into account at design phase to be anyhow efficient. That's what makes me suspicious - let's see if MS would be able to extend features at all in sane and efficient ways to be on par. I wouldn't bet on it "by default" granted that MS recently mostly good in marketing and suxx at everything else. Btrfs haves particular name behind design. At least Chris Mason dares to admit he architected this thing. And who is from MS side? Just "MS"? No names of architects, etc? Hmmph, does not looks too promising.

3) Well, its windows. Its proprietary nature, closed ecosystem, lack of internal details and closed sources are making it exceptionally boring for me. So I havent even bothered myself to learn details about ReFS. I would never use it anyway since I'm not silly enough to step into vendor-locked solutions anymore.

As you can read in my post you replied to, I questioned the following statement:
If Btrfs will be on every hard drive (including SSDs), the standard file system in Windows and MacOS (market share) has to be Btrfs! No 3rd party driver.

Now you get my point?

I got it, BUT I do not think it would happen this way. Furthermore, driver model of NT haves nothing to do with Linux, so it's not like if Linux kernel module source too much use under Windows. You'll have to rewrite driver almost completely anyway. Sure, maybe it is possible to copy-paste some code with math/parsing/etc. But again, in Linux people care about solving their tasks in efficient ways. They do not give it a fsck how hard or easy it would be for MS to integrate their code into Windows. That's IMO perfectly fair, since MS does not bothers self too much to share code on sane terms and take care about mutual advantages. Quite similar could be told about Apple as well - their overall attitude hardly can be called opensource-friendly IMO. So it is really wrong for them to complain others could be not in mood to cooperate with them. GPL works well for Linux and it's not like if someone going to change that (and it's technically hard anyway). If you haven't got it, in opensource world, people join their efforts to solve THEIR problems in efficient ways as long as they share ideas about terms and goals. This means, if MS or Apple want to use btrfs - it is very unlikely Linux devs would care about it. So it is up to apple and MS what to do, if they think they need such filesystem as default FS. They can rewrite driver, agree to make driver (or whole kernel, depends if it can be called "linking") GPLed, or do whatever stuff they want. Market share? Well, I do not see why it matters in case of filesystem meant for internal drives and multi-disk storages. That's not a very good choice for filesystem on flash sticks, etc which everyone inserts in each and every computer with arbitrary OS around.

And filesystem is here and works. Everyone who really needs it can just go use Linux, it costs nothing (unless you're in mood to pay for commercial support), does not puts you to vendor locks, and Linux is not anyhow worse than anything else around, especially in right hands. There is also option someone can write 3rd party driver like it happened in ext2fsd which can mount ext4 in windows. But I wouldn't really count on it. Interestingly, MS aggressively pused filesystem incompatibility at NT times. Its rather funny to see how they could get the very same policy applied to their butts (for different reasons). Gives me a good laugh . "Treat others the way you want to be treated". Something that MS and Apple should learn.