At least it's no btrfs. What a disaster that filesystem's been.
ZFS on Linux: Unlistable and disappearing files
21–30 of 168 posts
Re: ZFS on Linux: Unlistable and disappearing files
#22Wow that's an old Kernel! https://linux.slashdot.org/story/16/01/31/0424221/linux-kern...
[deleted]
Re: ZFS on Linux: Unlistable and disappearing files
#23Re: ZFS on Linux: Unlistable and disappearing files
#24Looks like they're on top of the causes and solution. But there's a caveat: possible orphans. https://github.com/zfsonlinux/zfs/issues/7401#issuecomment-3...
We will work out a solution for people affected so that they can get those orphaned files back.
Re: ZFS on Linux: Unlistable and disappearing files
#25basically 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 2009ish, and found that a number of old files had at some point or another become corrupted, including ones I know for sure weren't in 2004. I'd been following ZFS somewhat since Sun had demoed it, including a depressing spell after Apple almost moved to it then quit, but it was my own personal actual losses that pushed me to move over.
End to end checksumming and other integrity features just plain should be universal at this point. Should have been a decade ago or more in fact. We have so much incredibly important data now that is digital only and nowhere else, and memory and storage have both become very cheap at the general population level. It's shameful that anyone should still be losing data or experiencing anxiety years or even decades down the line. Integrity, basic levels of security/privacy, and flexible, high integrity replication should all be native level features of any data store system. "Decades old" filesystems just plain absolutely do not cut it, no does anything newer that doesn't include those promises at least as options. Bugs are unfortunate, and I hope this prompts ZoL and associated projects under the OpenZFS umbrella to double check their automated unit and stress tests. Sun rightly made a big deal of that on release. Even so, I wholeheartedly believe that ZFS or the like are far better primitives for a data storage scheme then older FS (or many newer ones for that matter).
Re: ZFS on Linux: Unlistable and disappearing files
#26At least it's no btrfs. What a disaster that filesystem's been.
Is there a stable (loaded word, I know) versioning file system available for Linux?
Re: ZFS on Linux: Unlistable and disappearing files
#27Earlier quoted context omitted.
> We will likely have some way to recover the orphaned files (like ext4’s lost+found) and fix the directory sizes in the very near future. How should people behave right now? Will normal usage of production filesystems erase data, or will read/write activity leave the potentially-orphaned files in place? You've also mentioned snapshots being tricky in the thread. Should people stop creating snapshots in case orphaned…
Existing data is unlikely to be lost, but I strongly suggest that existing systems get off 0.7.7 if they are on it. Having to figure out where the orphaned files belonged would be very inconvenient.
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.
Re: ZFS on Linux: Unlistable and disappearing files
#28At least it's no btrfs. What a disaster that filesystem's been.
Is there a stable (loaded word, I know) versioning file system available for Linux?
LVM can do snapshots and Redhat is working on its own hybrid storage management solution based on xfs called stratis[0]. Redhat deprecated btrfs recently. I don't think that means anything more than Redhat has lots of xfs devs and no btrfs devs.
[0] https://www.phoronix.com/scan.php?page=news_item&px=Stratis-...
Re: ZFS on Linux: Unlistable and disappearing files
#29Earlier quoted context omitted.
Existing data is unlikely to be lost, but I strongly suggest that existing systems get off 0.7.7 if they are on it. Having to figure out where the orphaned files belonged would be very inconvenient.
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.
Re: ZFS on Linux: Unlistable and disappearing files
#30basically 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…
I relate to your usage scenario, and my requirements are similar, and so are my frustrations with older filesystems: little or placebo protections against silent data corruption, lack of CoW semantics, pain of deduplication.
But on the other hand, over the years, I've heard so much FUD -- or underwhelming rumours that may-or-may-not be FUD -- about both ZFS and btrfs that have made me very reluctant to jump ship, and instead lean on an extensive suite of homemade processes and procedures that badly try to replicate subsets of features I'd expect a modern filesystem to provide. This is likely a Bad Idea, but my trust model right now can better stomach me losing data due to my bug, than someone else's.
I think what I'd like to see is widespread deployments, deployments-by-default, and better, persistent press and/or marketing surrounding *ZFS or brtfs, such that I wouldn't feel like an early adopter when using these filesystems. I'm actually glad Apple secretly wrote a filesystem with some of the same ideas, and deployed it to production on millions of (users') devices in the wild, because it raises the profile of modern filesystems and increases the likelihood that comparable alternatives will see more attention.