ben42153251

It's the default cache pool.

We use the parity to generate a raw disk as if it had FAILED and mount it READ ONLY somewhere else so that when BTRFS reads off the physical disk and a checksum fails, it can check if the parity generated version of that drive contains the correct version of the file. Eg imagine standard RAID 5, 1 disk fails, parity is re-creating the whole disk virtually.

I just realised that in a dual parity configuration we actually have a total of 3 copies of a file potentially available to BTRFS (including the original physical disk). When reading data only the disk containing a file would need to be spinning, BTRFS could be told another copy of the file is available but UNRAID would only need to spin up the other drives if a checksum failed and it was necessary to read the file from the parity generated copy. Essentially my whole idea is to an extent "lie" to BTRFS that it's in a mirror configuration using a virtual parity generated disk when necessary to facilitate the other half of the "mirror". Limetech please consider writing a BTRFS interoperability layer so it can use a parity generated disk to get a copy of a file if its corrupted on the physical disk. The first step is starting with the 6.9 release, make BTRFS the default file system.

No because each disk would still contain its own BTRFS file system rather than being striped. It may become necessary to use UNRAID to access those individual file systems if a slightly modified version of BTRFS was used (instead of an interoperability layer) but the idea is for each disk to retain its own file system.

If parity can virtualize a failed drive (continued access to data), why couldn't that parity virtualized version of the data be available to a physical working BTRFS formatted disk for the purpose of providing a second copy of the data so that BTRFS scrub could replace corrupted data? Perhaps a slightly modified version of BTRFS or interoperability layer would be needed for UNRAID but I don't see why UNRAID could not have similar levels of data integrity to ZFS mirror or BTRFS mirror. The UNRAID parity check could be modified to run BTRFS scrub PRIOR to the parity check and if an inconsistency is found then virtualize the disk reporting corrupt data and run another scrub on the physical disk using the virtualized disk as the mirror source to restore the corrupted data. Expanding my thought bubble... why couldn't UNRAID (in the background) generate parity virtualized versions of ALL physical disks at ALL times such that BTRFS would always have access to a backup copy of a file if a read checksum failed? Then just kick the corrupt disk from the array and rebuild with a new drive. To avoid a read speed penalty, BTRFS should only draw on the virtualised parity copy of the data when a checksum fails reading data off the physical disk.

I have an idea that could potentially solve bit-rot on UNRAID when the user uses a BTRFS file system. BTRFS checksums data and upon reading, if the data does not match the checksum it will report an error and refuse to read the corrupted data. If UNRAID parity was changed from real-time to very slightly delayed, if BTRFS threw a checksum error, UNRAID could mark the drive as bad and not include corrupted data into the parity allowing the user to restore the good copy of the data when replacing the hard drive. Implementation strategies could include using the mirrored cache drives to store real-time changes for the parity BUT NOT IMMEDIATELY COMMIT THEM, such that if BTRFS checksum throws an error, parity could DISCARD the corrupted data from being included into the array. Thoughts?

Hey folks, I'm putting together an unraid box, I have some questions: 1) Do all disks need to be spinning to write data or just the data disk + parity? 2) Are people seeing longer lifespan from drives by leaving them spun down most of the time with rarely accessed data? Whats the oldest drive you have?

I'm planning to run Unraid as a virtual machine on Proxmox with a PCI sata controller passed through. I want to run Unraid off a virtual disk sitting on top of my mirrored zfs file system in Proxmox. Then I don't increase the risk of stability issues from the usb pass through Risk corruption of the fat32 file system Eventual failure of the usb stick Take the risk of potentially not being able to get a license for another USB stick in the future Instead of having to backup a USB stick I can automate backups via Proxmox, the USB stick seems like a huge disadvantage. How can I run and license Unraid entirely on the virtual machine?

This would be a very simple feature to implement, Allow mirroring of two USB UNRAID boot keys, this way if one fails there is an exact copy on the other that can simply be booted and the failed USB key rebuilt later from the web interface. Simple MDADM raid I think would suffice, I intend to run UNRAID unattended, the motherboard has remote management interface including even viewing the BIOS over remote. Problem is I can't fix a failed USB key, but I could just boot a mirrored one. .......... Actually, you know what would be even better than this? An option in the web interface to "backup" to a spare USB key, that just uses DD to copy the entire disk to the backup usb key. That way when we are happy with installations it's possible to take a backup of the boot system.