Live data from Hacker News

ZFS on Linux: Unlistable and disappearing files

github.com

151–160 of 168 posts

Re: ZFS on Linux: Unlistable and disappearing files

#151

Earlier quoted context omitted.

I paid good money to Apple so something like that would not happen, so yeah I’d be villifying them. You bet!

As opposed to the free RedHat Enterprise Linux operating system

No, I love to hate redhat because they are the most incompetent company in the computer industry’s history; just take a look at their priority 1 bugs at bugzilla.redat.com and the picture becomes crystal clear. (I’m forced to perform system engineering on RHEL every day and a lot, so my hate for it grows daily.)

Re: ZFS on Linux: Unlistable and disappearing files

#152
post #142

Earlier quoted context omitted.

If it's a one time throwaway tool, then it doesn't need lost+found!

I was talking more about the idea of a lost+found directory. Brian suggested that we make it ‘.zfs/lost+found‘, which might be what we do. I am leaning toward extending scrub to add the function when a flag for an erratum check is passed. That implies that the tool would be a part of the driver so that it can be done online for minimal downtime.

But something is majorly wrong with this approach if you can even have orphaned files! This should be impossible on ZFS!

Re: ZFS on Linux: Unlistable and disappearing files

#153
post #144

Earlier quoted context omitted.

I suggest completely backing out the code in question and using a FreeBSD or an illumos based system like SmartOS. That's what I suggest. metadata are not files so they have no business going into lost+found.

> I suggest completely backing out the code in question This makes sense and we did that. It does not fix the fact that datasets exist where directories have incorrect sizes and files are orphaned because of the bad patch. > and using a FreeBSD or an illumos based system like SmartOS. That's what I suggest. While those are fine choices, they are not immune to bugs either. We had a space map corruption bug that we inh…

I do not mean to discourage people from using those systems, but it is silly to adopt them because a bug got past joint OpenZFS review and landed in the Linux port first.

That’s your opinion and while I extremely disagree with it, it is what it is. It might be even true in the case if ZFS on Linux team but on the whole of GNU/Linux, my professional experience is that the amount of bugs and breakage is much higher than on BSD or illumos based operating systems, and to me, quality and stability are the most important things. For me a computer is a tool to make money and so reliability of hardware and especially the software trumps everything else. In fact, apart from reliability and simplicity nothing else is important to me when it comes to software.

Re: ZFS on Linux: Unlistable and disappearing files

#154
post #144

Earlier quoted context omitted.

> I suggest completely backing out the code in question This makes sense and we did that. It does not fix the fact that datasets exist where directories have incorrect sizes and files are orphaned because of the bad patch. > and using a FreeBSD or an illumos based system like SmartOS. That's what I suggest. While those are fine choices, they are not immune to bugs either. We had a space map corruption bug that we inh…

I do not mean to discourage people from using those systems, but it is silly to adopt them because a bug got past joint OpenZFS review and landed in the Linux port first. That’s your opinion and while I extremely disagree with it, it is what it is. It might be even true in the case if ZFS on Linux team but on the whole of GNU/Linux, my professional experience is that the amount of bugs and breakage is much higher tha…

Your postings reminded me of illumOS's existence, so I went looking for an arm build to no avail. You wouldn't happen to know if that is something that is available would you?

Re: ZFS on Linux: Unlistable and disappearing files

#155
post #115

Earlier quoted context omitted.

Huh. I had that same problem on two machines running Tumbleweed a couple of months ago. In both cases, the only working approach I found was to wipe the root partition and install from scratch. /home was in a separate partition, so it was not a tragedy, but annoying nevertheless. This has never happened to me before, unless the underlying hardware was about to retire.

Tumbleweed is a rolling edge release. I get wonky desktops and other problems all the time when I update.

That is true.

But I have used Gentoo, another rolling release distro, before that (way before that, actually), and I never had such a problem with Gentoo, even on the unstable branch.

From what I hear Arch users tell about their distro of choice, Arch does not give them this kind of headache, either.

And last but not least, the reason I took the plunge and went for Tumbleweed was that the project uses extensive automatic testing to ensure they do not break anything.

Do not get me wrong, I still use Tumbleweed on both machines and do not see that changing for the foreseeable future. I know what I signed up for. ;-)

Re: ZFS on Linux: Unlistable and disappearing files

#156
post #142

Earlier quoted context omitted.

I was talking more about the idea of a lost+found directory. Brian suggested that we make it ‘.zfs/lost+found‘, which might be what we do. I am leaning toward extending scrub to add the function when a flag for an erratum check is passed. That implies that the tool would be a part of the driver so that it can be done online for minimal downtime.

But something is majorly wrong with this approach if you can even have orphaned files! This should be impossible on ZFS!

That's why it's a bug?

Re: ZFS on Linux: Unlistable and disappearing files

#157
post #144

Earlier quoted context omitted.

> I suggest completely backing out the code in question This makes sense and we did that. It does not fix the fact that datasets exist where directories have incorrect sizes and files are orphaned because of the bad patch. > and using a FreeBSD or an illumos based system like SmartOS. That's what I suggest. While those are fine choices, they are not immune to bugs either. We had a space map corruption bug that we inh…

I do not mean to discourage people from using those systems, but it is silly to adopt them because a bug got past joint OpenZFS review and landed in the Linux port first. That’s your opinion and while I extremely disagree with it, it is what it is. It might be even true in the case if ZFS on Linux team but on the whole of GNU/Linux, my professional experience is that the amount of bugs and breakage is much higher tha…

[citation needed]

Re: ZFS on Linux: Unlistable and disappearing files

#158
post #78

Probably obvious, but hooray for open source software! What a fantastic response to the bug.

Imagine if this had happened to Apple, everyone and his dog would be rolling over each other villifying them.

Like storing the passphrase in the hint field...?

Shit happens. Software is hard.

Re: ZFS on Linux: Unlistable and disappearing files

#159

Earlier quoted context omitted.

I do not mean to discourage people from using those systems, but it is silly to adopt them because a bug got past joint OpenZFS review and landed in the Linux port first. That’s your opinion and while I extremely disagree with it, it is what it is. It might be even true in the case if ZFS on Linux team but on the whole of GNU/Linux, my professional experience is that the amount of bugs and breakage is much higher tha…

Your postings reminded me of illumOS's existence, so I went looking for an arm build to no avail. You wouldn't happen to know if that is something that is available would you?

https://wiki.illumos.org/display/illumos/Raspberry+Pi+Bring-...

that's the closest you're going to get right now, unless you jump in and help out.

Re: ZFS on Linux: Unlistable and disappearing files

#160

Earlier quoted context omitted.

I do not mean to discourage people from using those systems, but it is silly to adopt them because a bug got past joint OpenZFS review and landed in the Linux port first. That’s your opinion and while I extremely disagree with it, it is what it is. It might be even true in the case if ZFS on Linux team but on the whole of GNU/Linux, my professional experience is that the amount of bugs and breakage is much higher tha…

[citation needed]

How can one cite one's professional experience? But okay: bugzilla.redhat.com. Take a look at priority 1 bugs for epic breakage.
Post reply on HN