Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus: Don't Use ZFS

realworldtech.com

Post reply on HN
Print view View original

441–450 of 571 posts

Re: Linus: Don't Use ZFS

#441

Post by toyg »

notacoward wrote: post #418
morning_gelato wrote: post #337

Earlier quoted context omitted.

Danese Cooper, one of the people at Sun who helped create the CDDL, responded in the comment section of that very video: Lovely except it really was decided to explicitly make OpenSolaris incompatible with GPL. That was one of the design points of the CDDL. I was in that room, Bryan and you were not, but I know its fun to re-write history to suit your current politics. I pleaded with Sun to use a BSD family license o…

This needs to be more widely known. Sun was never as open or innovative as its engineer/advertisers claim, and the revisionism is irksome. I saw what they had copied from earlier competitors like Apollo and then claimed as their own ideas. I saw the protocol fingerprinting their clients used to make non-Sun servers appear slower than they really were. They did some really good things, and they did some really awful t…

The thing is - it was a time of pirates. In an environment defined by the ruthlessness of characters like Gates, Jobs, and Ellison, they were among the best-behaved of the bunch. Hence the reputation for being nice: they were markedly nicer than the hive of scum and villainy that the sector was at the time. And they did some interesting things that arguably changed the landscape (Java etc), even if they failed to fully capitalize on them.

(In many ways, it still is a time of pirates, we just moved a bit higher in the stack...)

Re: Linus: Don't Use ZFS

#443

Post by usefulcat »

monocasa wrote: post #156
usefulcat wrote: post #128

Earlier quoted context omitted.

> With that, they do expose a userspace filesystem driver interface, FUSE. Yes, which Linus has also poo-pooed: "People who think that userspace filesystems are realistic for anything but toys are just misguided."

I mean, he's right. VFS, VMM, and buffer cache are all three sides of the same coin. Nearly every system that puts the FS in user space has abysmal performance; the one exception I can think of off the top of my head is XOK's native FS which is very very very different than traditional filesystems at every layer in the stack, and has abysmal performance again once two processes are accessing the same files.

Oh, I totally agree. But between that statement and this one about ZFS, the takeaway seems to be: for filesystems on Linux, go GPL or go home. Which is fine if that's his attitude, but if so I do wish he'd be more direct about it rather than making claims that are questionable at best (e.g. "ZFS is not maintained"--wtf?).

Re: Linus: Don't Use ZFS

#444

Post by awused »

m4rtink wrote: post #376
awused wrote: post #286

Earlier quoted context omitted.

>Isn't this a problem for any over provisioned storage pool ? ZFS doesn't over-provision anything by default. The only case I'm aware of where you can over-provision with ZFS is when you explicitly choose to thin provision zvols (virtual block devices with a fixed size). This can't be done with regular file systems which grow as needed, though you can reserve space for them. File systems do handle running out of spac…

Can't you over provision even just by creating too many many snapshots ? Even if you never make the filesystems bigger then the backing pool, the snapshots will allocate some blocks from the pool and over time, boom.

Snapshots can't cause over-provisioning, not for file systems. If I mutate my data and keep snapshots forever, eventually my pool will run out of free space. But that's not a problem of over-provisioning, that's just running out of space.

With ZFS, if I take a snapshot and then delete 10GB of data my file system will appear to have shrunk by 10GB. If I compare the output of df before and after deleting the data, df will tell me that "size" and "used" have decreased by 10GB while "available" remained constant. Once the snapshot is deleted that 10GB will be made available again and the "size" and "available" columns in df will increase. It avoids over-provisioning by never promising more available space than it can guarantee you're able to write.

I think you're trying to relate ZFS too much to how LVM works, where LVM is just a volume manager that exposes virtual devices. The analogue to thin provisioned LVM volumes is thin-provisioned zvols, not regular ZFS file systems. I can choose to use ZFS in place of LVM as a volume manager with XFS as my file system. Over-provisioned zvols+XFS will have functionally equivalent problems as over-provisioned LVM+XFS.

Re: Linus: Don't Use ZFS

#445

Post by Unklejoe »

thomasfedb wrote: post #439
stiray wrote: post #321

Earlier quoted context omitted.

Btrfs crashed for me on two occations, last time, around 2 years back I have installed zfs (which I am using for ~10 years on FreeBSD server) which works like a charm since then. I understand Linus reasoning but there is just no way I will install btrfs, like ever. I rather dont update kernel (I am having zfs on fedora root with degular kernel updates and scripts which verify that everything is with kernel modules pr…

I'd avoid making an argument for or against a filesystem on the basis of anecdotal evidence.

For your own personal use, your own personal anecdotes are really all that matter.

Re: Linus: Don't Use ZFS

#446

Post by kuon »

ksec wrote: post #330
kuon wrote: post #153

I don't blame Linus, but I use ZFS a lot. I'll drop ZFS the moment I have an alternative with the same features: - disk management with simple commands that can create raids in any modern configuration - zero cost snapshots - import/export (zfs send/recv) - COW and other data integrity niceties - compression, encryption, dedup, checksums I am very grateful to the OpenZFS community, and I think they deserve praises fo…

So why drop ZFS then?

I don't want to drop ZFS for technical reasons, but I do share some of Linus concerns about licensing.

Re: Linus: Don't Use ZFS

#447

Post by kqr »

Unklejoe wrote: post #445
thomasfedb wrote: post #439

Earlier quoted context omitted.

I'd avoid making an argument for or against a filesystem on the basis of anecdotal evidence.

For your own personal use, your own personal anecdotes are really all that matter.

Your personal anecdotes are indeed all that matter when it comes to describing your past.

When it comes to predicting your future, though, your personal anecdotes may not hold water to more substantial data.

Re: Linus: Don't Use ZFS

#448

Post by kqr »

btilly wrote: post #35
Hamuko wrote: post #7

Earlier quoted context omitted.

That's his reasoning for not merging ZFS code, not for generally avoiding ZFS.

Here are his reasons for generally avoiding ZFS from what I consider most important to least. - The kernel team may break it at any time, and won't care if they do. - It doesn't seem to be well-maintained. - Performance is not that great compared to the alternatives. - Using it opens you up to the threat of lawsuits from Oracle. Given history, this is a real threat. (This is one that should be high for Linus but not…

This reminds me of the adaptation of a Churchill quote that "ZFS is the worst of the file systems, except for all others."

Re: Linus: Don't Use ZFS

#449

Post by awused »

HorstG wrote: post #394
awused wrote: post #286

Earlier quoted context omitted.

>Isn't this a problem for any over provisioned storage pool ? ZFS doesn't over-provision anything by default. The only case I'm aware of where you can over-provision with ZFS is when you explicitly choose to thin provision zvols (virtual block devices with a fixed size). This can't be done with regular file systems which grow as needed, though you can reserve space for them. File systems do handle running out of spac…

ZFS does overprovision all filesystems in a zpool by default. Create 10 new filesystems and 'df' will now display 10x the space of the parent fs. A full fs is handled differently than your volume manager running out of blocks. But the normal case is overprovisioning.

That is not over-provisioning, it's just that 'df' doesn't have the concept of pooled storage. With pools it's possible for different file systems to share their "available" space. BTRFS also has its own problems with ouput when using df and getting strange results.

If I have a 10GB pool and I create 10 empty file systems, the sizes reported in df will be 100GB. It's not quite a lie either, because each of those 10 file systems does in fact have 10GB of space available I could write 10GB to any one of them. If I write 1GB to one of those file systems, the "size" and "available" spaces for the other nine will all shrink despite not having a single byte of data written to them.

With ZFS and df the "size" column is really only measuring the maximum possible size (at this point in time, assuming nothing else is written) so it isn't very meaningful, but the "used" and "available" columns do measure something useful.

Re: Linus: Don't Use ZFS

#450

Post by armitron »

spamizbad wrote: post #306
lizknope wrote: post #293

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Common_Development_and_Distrib... Some people argue that Sun (or the Sun engineer) as creator of the license made the CDDL intentionally GPL incompatible.[13] According to Danese Cooper one of the reasons for basing the CDDL on the Mozilla license was that the Mozilla license is GPL-incompatible. Cooper stated, at the 6th annual Debian conference, that the engineers who had written the S…

Wow... talk about cutting off your nose to spite your face. Oracle ended up abandoning OpenSolaris within a year or so. Edit: Nevermind, debunked by Bryan Cantrill. It was to allow for proprietary drivers.

Not at all really. Danese Cooper says that Cantrill is not a reliable witness and one can say he also has an agenda to distort the facts in this way [1].

[1] https://news.ycombinator.com/item?id=22008921

Post reply on HN