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

ZFS on Linux: Unlistable and disappearing files

github.com

Post reply on HN
Print view View original

31–40 of 168 posts

Re: ZFS on Linux: Unlistable and disappearing files

#31

Post by luke0016 »

ryao wrote: post #29
luke0016 wrote: post #27

Earlier quoted context omitted.

I have a fairly specific question - I'm in the process of migrating a large array onto another disk using zfs send and receive (6TB). It's been at it for about 2 days now. After the migration, I plan to destroy and recreate a larger array and send it back. If the pool is not being read/written to by anything else, am I safe? Or should I stop the send and receive and downgrade? Thank you for the hard work.

You should be fine. The DMU that handles send/recv is unaffected as long as the snapshots at the source were not taken after 0.7.7 experienced an ENOSPC on file creation.

As far as I know, it has never experienced an ENOSPC error. It was mentioned elsewhere that a procedure is being developed to detect orphaned files that arise from this bug. Would it be a good idea for me to keep the original array around long enough to run through that procedure just in case?

Re: ZFS on Linux: Unlistable and disappearing files

#32

Post by ryao »

luke0016 wrote: post #31
ryao wrote: post #29

Earlier quoted context omitted.

You should be fine. The DMU that handles send/recv is unaffected as long as the snapshots at the source were not taken after 0.7.7 experienced an ENOSPC on file creation.

As far as I know, it has never experienced an ENOSPC error. It was mentioned elsewhere that a procedure is being developed to detect orphaned files that arise from this bug. Would it be a good idea for me to keep the original array around long enough to run through that procedure just in case?

I am the developer who volunteered to develop the code to fix things. Anyway, there is no reason to avoid send/recv with 0.7.7. Send/recv will neither trigger this bug nor make it worse if it were triggered.

Re: ZFS on Linux: Unlistable and disappearing files

#33

Post by Arbalest »

beedogs wrote: post #21

At least it's no btrfs. What a disaster that filesystem's been.

A disaster for enterprise perhaps. I use only a subset of features (such as subvolumes and snapshots and a little RAID 1) and have never had problems. With the way some people talk about it, it sure sounds like it never worked at all.

Re: ZFS on Linux: Unlistable and disappearing files

#34

Post by snvzz »

aidenn0 wrote: post #13
zorkw4rg wrote: post #8

basically the reason I like my filesystems a few decades old and mature, I would not trust zfs or btrfs with anything critical.

Are you still using ext2 then? Ext3 was 2001, and ZFS was 2005. JFS2 is only 19 years old so doesn't quite meet the "decades" requirement.

He's likely referring to XFS, which meets the requirement.

Re: ZFS on Linux: Unlistable and disappearing files

#35

Post by luke0016 »

ryao wrote: post #32
luke0016 wrote: post #31

Earlier quoted context omitted.

As far as I know, it has never experienced an ENOSPC error. It was mentioned elsewhere that a procedure is being developed to detect orphaned files that arise from this bug. Would it be a good idea for me to keep the original array around long enough to run through that procedure just in case?

I am the developer who volunteered to develop the code to fix things. Anyway, there is no reason to avoid send/recv with 0.7.7. Send/recv will neither trigger this bug nor make it worse if it were triggered.

I understand - what I meant to say is that I cannot be sure that the array never ran into an ENOSPC issue prior to the snapshot. Given that, should I keep the old array around until I can do whatever is recommended to detect potential orphans resulting from the bug?

Edit: And thank you, again.

Re: ZFS on Linux: Unlistable and disappearing files

#36

Post by ams6110 »

xoa wrote: post #25
zorkw4rg wrote: post #8

basically the reason I like my filesystems a few decades old and mature, I would not trust zfs or btrfs with anything critical.

I have been running ZFS on macOS (OS X), illumos and Solaris for a good 7 years or so now. A major part of the reason I switched over fully, despite some warts, was that I experienced actual and significant data rot from stuff I was carrying forward under XFS (IRIX), HFS, etc. I don't consider my personal stuff to go back that long, but I still have things from 1993 or so that matter to me. I did a review around 2009…

It sounds like you are suggesting that checksums and other integrity features obviate the need to back up your important files.

Re: ZFS on Linux: Unlistable and disappearing files

#37

Post by codetrotter »

xxpor wrote: post #12
newnewpdro wrote: post #6

Why is the thread title hyphenated? It made me expect there's a utility called "zfs-bug" causing data loss.

The OP appears to speak German natively. In German they are much more hyphen happy than English. It's probably the most common error I see among German speakers typing English.

Same thing in Norway wrt hyphenation; we use hyphens a lot. And I am well aware that native English speakers use them much less frequently but I intentionally use hyphens in places where an English speaker would not when there is ambiguity that can be resolved by using them. I also use hyphens for aesthetic reasons sometimes just based on what looks better to me.

Also like a sibling commenter said, it’s not necessarily an error to hyphenate even though people that grew up in the US or the UK wouldn’t.

In the case of OP title I would not have hyphenated though.

Re: ZFS on Linux: Unlistable and disappearing files

#38

Post by ryao »

luke0016 wrote: post #35
ryao wrote: post #32

Earlier quoted context omitted.

I am the developer who volunteered to develop the code to fix things. Anyway, there is no reason to avoid send/recv with 0.7.7. Send/recv will neither trigger this bug nor make it worse if it were triggered.

I understand - what I meant to say is that I cannot be sure that the array never ran into an ENOSPC issue prior to the snapshot. Given that, should I keep the old array around until I can do whatever is recommended to detect potential orphans resulting from the bug? Edit: And thank you, again.

There is no reason to do that here. Send/recv makes a perfect copy as far as this is concerned.

You are welcome. Also, the proper term is pool.

Re: ZFS on Linux: Unlistable and disappearing files

#39

Post by boomboomsubban »

ams6110 wrote: post #36
xoa wrote: post #25

Earlier quoted context omitted.

I have been running ZFS on macOS (OS X), illumos and Solaris for a good 7 years or so now. A major part of the reason I switched over fully, despite some warts, was that I experienced actual and significant data rot from stuff I was carrying forward under XFS (IRIX), HFS, etc. I don't consider my personal stuff to go back that long, but I still have things from 1993 or so that matter to me. I did a review around 2009…

It sounds like you are suggesting that checksums and other integrity features obviate the need to back up your important files.

They're part of the same process, you need the checksums to know your backup is reliable and to tell you when your main files become corrupt. Backups alone aren't enough either.
Post reply on HN