Comment

Flamekebab@piefed.social ⁨5⁩ ⁨months⁩ ago

I was trying to use it for a mirrored setup with TrueNAS and found it to be flakey to the point of uselessness. I was essentially told that I was using it wrong because I had USB disks. It allowed me to set it up and provided no warnings but after losing my test data for the fifth time (brand new disks - that wasn’t the issue) I gave up and setup a simple rsync job to mirror data between the two ext4 disks.

If losing power effectively wipes my data then it’s no damn use to me. I’m sure it’s great in a hermetically sealed data centre or something but if I can’t pull one of the mirrored disks and plug it into another machine for data recovery then it’s no damn good to me.

source

Sort:hotnew top

Andres4NY@social.ridetrans.it ⁨5⁩ ⁨months⁩ ago
@Flamekebab @non_burglar Sounds like snapraid might be a better fit for your needs. Since it runs over top of the filesystem, if you lose a disk you can still access files from the other disk(s). It's better than rsync, in that it would provide regular data validation ('snapraid scrub' once per week or so). It is more designed to work in raid5 rather than mirroring (raid1) setup, however.
source
JGrffn@lemmy.world ⁨5⁩ ⁨months⁩ ago
Wait so you built a pool using removable drives, and was surprised it didn’t work? Lmao

That’s like being angry that a car wash physically hurt you because you drove in on a bike, then using a hose on your bike and claiming that the hose is better than the car wash.

Zfs is a low level system meant for pcie or sata, not USB, which is many layers above sata & pcie. Rsync was the right choice for this scenario since it’s a higher level program which doesn’t care about anything other than just the data and will work over USB, Ethernet, wifi, etc., but you gotta understand why it was the right choice instead of just throwing shade at one of the most robust filesystems out there just because it wasn’t designed for your specific usecase.

source
- Flamekebab@piefed.social ⁨5⁩ ⁨months⁩ ago
  I was told a tool was a resilient approach to drive management.
  It wasn’t, outside of a very specific set of circumstances.
  
  Your analogy not only makes no sense but is exactly why I’m hostile about this. I’m not an expert at the specific limitations of a niche hard disk technology is, I must be a fucking moron or something, and ridicule is a clearly an appropriate reaction.
  
  My idea of a useful tool for dealing with hard disks is not one that loses its shit when a hard disk is temporarily disconnected.
  That is not a ridiculous assumption. If that’s an issue then that should be made abundantly clear.
  
  I assigned drives based on serial number and passed them through to TrueNAS and it couldn’t handle that reliably. I do not think I was asking for the moon on a stick.
  
  The USB interface is a temporary measure, I was going to move the disks to an internal setup after testing but if it can’t handle something that basic then like fuck am I trusting it with something like migrating from USB SATA to internal SATA.
  
  If I need both disks to access mirrored data then it’s as useful as a chocolate teapot.
  
  source
non_burglar@lemmy.world ⁨5⁩ ⁨months⁩ ago
Ah, I hear you, and sorry you had that experience. GUI controls of ZFS aren’t usually very intuitive.

Also, ZFS assumes it has direct access to the block device, and certain USB implementations (not UAS) use ~sync~ operations that sit between the HAL and userland somewhere. So ZFS likes direct-attached storage, it’s a caveat to be sure.

If you ever change your mind, klarasystems.com/zfs/ has a ton of reading and tutorials on ZFS.

source
- Flamekebab@piefed.social ⁨5⁩ ⁨months⁩ ago
  I found the whole experience tremendously frustrating and as you can see from some of the other responses and votes, the community does not consider that to be a reasonable reaction.
  
  Hence why I bailed on the whole thing. I don’t need the grief.
  
  source