starbetrayer Posted May 19, 2018 Share Posted May 19, 2018 Dear all, I have been browsing the forums of Unraid for quite a while, learning from the community. It looks like a really nice piece of software and I am very much considering switching to it. I am currently using Openmediavault via a virtual machine running on vmware ESXi and passing the drives through RDM. I have a couple of questions where I would like some answers if possible. I thank the community in advance for the help. 1. I have existing drives formatted in btrfs with data, can I import them directly to the new array or will they need to be reformated and emptied ? 2. a) I understand that Unraid is centered around btrfs and xfs, but one thing I want to make sure is that Unraid doesn't write to the drives or modify the filesystems of the data drives. Is that a correct statement ? 2. b) If I were to take a data drive from the array, can I plug it to another machine with Ubuntu and Debian and read the data ? 3. I understand Unraid to be a RAID JBOD with 1 or two parity drives.How well does the parity work ? What are the best practices ? 4. I believe I understand the disk shares and user shares. I would be using disk shares, very likely. The way user shares work to my understanding is that they spread the data across disks, and while practical, I see this being dangerous (see 2) b)) 5. Are cache drives necessary ? If not there, what are the disdvantages ? 6. Are VMs supposed to go to the cache drives ? 7. Are you guys backing up your array to the cloud ? If yes, what is the best provider and method to do it ? Looking forward to your answers. Starbe Link to comment
pwm Posted May 19, 2018 Share Posted May 19, 2018 30 minutes ago, starbetrayer said: 1. I have existing drives formatted in btrfs with data, can I import them directly to the new array or will they need to be reformated and emptied ? They would normally need to be reformatted - unRAID has a special requirement about the start offset of the paritition. Possibly gparted might be used to shrink and move the parititions to the correct start sector. 31 minutes ago, starbetrayer said: 2. a) I understand that Unraid is centered around btrfs and xfs, but one thing I want to make sure is that Unraid doesn't write to the drives or modify the filesystems of the data drives. Is that a correct statement ? I don't really understand the question - unRAID has to write to the parititions when mounting them. After that, unRAID has no reason to write to the paritition unless you want to perform some file operations. 32 minutes ago, starbetrayer said: 2. b) If I were to take a data drive from the array, can I plug it to another machine with Ubuntu and Debian and read the data ? Yes - there is nothing strange with the formatting of the drives. Any standard Linux installation can read the data disks. 33 minutes ago, starbetrayer said: 3. I understand Unraid to be a RAID JBOD with 1 or two parity drives.How well does the parity work ? What are the best practices ? It works really well. But since it doesn't stripe, you don't get the bandwidth of a real RAID. On the other hand, you don't need to spin up all disks to read a file. And if you have n parity drives and lose n+1 disks, then the remaining data disks will still hold valid data since each data disk has a stand-alone file system. If you don't shut down the array normally, unRAID will require a parity scan to find and correct any parity mismatch caused by the last disk changes not having been fully flushed to disk. Each data disk will behave as in a normal Linux file server, when it comes to the stability of the individual file systems. So you are likely to get a warning about replay or rollback of file system journal or in the case of BTRFS the last CoW operation might not have completed. You have similar options when replacing a broken disk - so the standard best practices of using disk supervision (SMART) and active event notification (mail) still holds true. You don't want to wait until you have a large number of disks with SMART issues before you start looking at repairing/replacing. And you want to regularly do a non-correcting parity scan to verify the integrity of the parity - which also verifies that the machine itself can be trusted. As with all file servers, the recommendation is to have a processor and RAM with ECC, but unRAID will not work worse than any other file server in case you don't have ECC. And as with all other file server solutions, parity doesn't replace the need for backup. Parity is mostly intended to improve availability - that you can access your data even with a broken disk and that you can replace the broken disk without restoring every single file on the array from the backup. 41 minutes ago, starbetrayer said: 4. I believe I understand the disk shares and user shares. I would be using disk shares, very likely. The way user shares work to my understanding is that they spread the data across disks, and while practical, I see this being dangerous (see 2) b)) Most people only use user shares. I prefer to only use disk shares, but that's because I prefer to decide 100% exactly where files are stored. User shares aren't dangerous - there are no black magic with distributing files. You have multiple options how to configure split levels. With split levels, you can make multiple files in the same directory end up on the same data disk. And if you configure so unRAID fills up disks, it will not constantly switch between target disks for every new directory created. 45 minutes ago, starbetrayer said: 5. Are cache drives necessary ? If not there, what are the disdvantages ? No, cache drives aren't necessary. unRAID can do well with 1gbit/s network interfaces, but without striping of the data, there is no way unRAID can get close to the transfer rate of 10gbit/s network interfaces. Cache drives can help if you want to improve the write speed when filling the array - and then let the mover transfer the files into the array at night. Cache drives can also be good for cache-only storage of virtual machines and other file data that needs a high transfer rate or a very high number of IO per second. unRAID isn't designed for use of SSD in the actual array, but the cache pool can make use of multiple disks with striping and mirroring when using BTRFS. 50 minutes ago, starbetrayer said: 6. Are VMs supposed to go to the cache drives ? It's highly recommended that they are stored on the cache pool, or that you have one or more standalone drives outside of the array for your VM. If having your VM in the array, then the write speed will suffer. And since you will get contention for writes to the parity drives, that will also affect transfer rates to other disks in the array. 52 minutes ago, starbetrayer said: 7. Are you guys backing up your array to the cloud ? If yes, what is the best provider and method to do it ? I'll mostly leave this for others to answer, since I use my own backup software. But it's quite common to install different Docker with backup software for different cloud providers. Link to comment
starbetrayer Posted May 19, 2018 Author Share Posted May 19, 2018 37 minutes ago, pwm said: They would normally need to be reformatted - unRAID has a special requirement about the start offset of the paritition. Possibly gparted might be used to shrink and move the parititions to the correct start sector. I don't really understand the question - unRAID has to write to the parititions when mounting them. After that, unRAID has no reason to write to the paritition unless you want to perform some file operations. Yes - there is nothing strange with the formatting of the drives. Any standard Linux installation can read the data disks. That's the part that I do not really understand. So what is the requirement for the start offset of the partition ? would this cause issues reading andmounting drives to another linux installation ? Does this create two partitions on the drives then ? Link to comment
pwm Posted May 19, 2018 Share Posted May 19, 2018 5 minutes ago, starbetrayer said: That's the part that I do not really understand. So what is the requirement for the start offset of the partition ? would this cause issues reading andmounting drives to another linux installation ? Does this create two partitions on the drives then ? Historically it has been 64 sectors for disks with 512 byte sectors. I'm not sure what the offset would be for disks with 4 kB addressing. No additional partition - the partition table specifies at what offset the partition starts. Whenever you add partitions to a drive, you have some form of align. In old times, you aligned the partitions to the start of a track, but tracks aren't meaningful concepts anymore since todays disks are addressed using logical addresses and only internally keep track of how many sectors you have on different tracks on different surfaces. unRAID just happens to be a bit more strict on the selected offset for the partition. And as I wrote earlier - any standard Linux installation can read the drives. The machine just looks at the partition table to know where the partition starts. Link to comment
JorgeB Posted May 20, 2018 Share Posted May 20, 2018 On later releases just using the correct starting sector is not enough, it needs a specific MBR signature, so you'll need to let unRAID format the disks. Link to comment
NewDisplayName Posted May 20, 2018 Share Posted May 20, 2018 Trust me, get unraid, its like heaven... if i just knew unraid some years ago... Also, its free trial, just try it, u will love it. For best performance, get some cheap ssds for cache drives. Link to comment
starbetrayer Posted May 22, 2018 Author Share Posted May 22, 2018 On 5/19/2018 at 10:41 AM, pwm said: Historically it has been 64 sectors for disks with 512 byte sectors. I'm not sure what the offset would be for disks with 4 kB addressing. No additional partition - the partition table specifies at what offset the partition starts. Whenever you add partitions to a drive, you have some form of align. In old times, you aligned the partitions to the start of a track, but tracks aren't meaningful concepts anymore since todays disks are addressed using logical addresses and only internally keep track of how many sectors you have on different tracks on different surfaces. unRAID just happens to be a bit more strict on the selected offset for the partition. And as I wrote earlier - any standard Linux installation can read the drives. The machine just looks at the partition table to know where the partition starts. I just pulled the plug, I ordered the Unraid Pro License ? Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.