Question thread for a new prospective unRAID user

[itsrumsey]

I have just obtained a new server to host unRAID (dual Xeon e5520s, 24GB RAM) and I have some questions before I purchase a license or drives to begin this project.  I'll probably keep using this thread to post more as they come to me but here is what is on my mind right now.

 

If my understanding is right unRAID stores files in a plain filesystem on the disks unlike RAID, meaning even if I rip the drives out and take them to another computer I can read files off the disks.

 

How does this work with regards to directory file structure if multiple files in a folder are on different disks?

 

For instance:

X:\folder\file1.txt

X:\folder\file2.txt

 

both files are on different drives.  How do they look when you view the disks on another computer?  The main reason I want to understand this is I am concerned about what happens if your unRAID USB drive fails, or if your motherboard or CPU fails and you have to upgrade to a new chipset / SATA controller.  How is it able to intelligently restore the "visible" file system so that can still use it, and aren't just left with 20TB of jumbled files?

[Squid]

If you put the drive into another computer, you would only see the file that is stored on that disk.  When the drives are installed in unRaid, you would see all of the files stored in that folder regardless of which drives they are on (unRaid combines it all for you to create a cohesive share.)

 

As far as if your mobo / cpu fails, all you pretty much have to do is replace it, and boot the system back up.  Nothing should change.

 

If your USB fails, you can setup another USB stick identically to the one that failed, boot it up and transfer your registration key over to the new one/

[JustinChase]

or, to put it another way.

 

unRAID stores complete files, not partial files.  i.e. track 1 of an album might be stored on disk1, track 2 on disk4, track3 on disk7, etc.

 

You'll only see track 1 if you put disk1 in another machine, but you'll have ALL of track 1, not just a part of it.

 

but, as stated above, just replace any faulty part and unRAID will see your files as it always has.

[itsrumsey]

But does it also store the directory structure across all drives?

 

In other words lets say the share is \\server\music\cdname.  Track 1 and Track 2 are on different drives.  What does the folder tree look like on the drives.

 

In other words if a share is written across multiple disks is the directory structure identical across those disks?  And if my unRAID configuration dies (USB dies), how am I able to recreate the user shares with just the information on the disks?

If the USB drive fails and the motherboard fries in the same day, but all of the disks are in 100% working order, is there any way to restore all my data shares in a readable way?  I know all the data will be there but hundreds of tracks split across multiple disks are of little use unless I have a way of restoring the shares information and browsing them cohesively.

[Squid]

The entire folder structure is not duplicated across single drives (what's the point?)  Only the folder structure containing the files is present (ie: if the Music share doesn't have any files stored on the disk why create a folder called Music on that particular disk)

 

You should keep a backup of the files on your usb stick (at least the *.cfg files in /config).  Pop them onto a new stick and your back in business.  Even without a backup of those files, unRaid automatically creates shares of all root folders on each drive, so you'll be back in business also, (although the security settings for those shares will only have the default values)

 

 

[JustinChase]

not as I think you imagine.

 

referring to my example, disk1 does not "know" track 2 is on disk 4 nor that track 3 is on disk 7.

 

However, they are all in the same directory structure.  i.e. /Music/Artist/Album/

 

unRAID just combines all items in /Music/Artist/Album/ into the same 'share' no matter where the actual files reside.

 

As has been mentioned, if your usb dies, get a new one, put your license file on the new one, boot up unRAID, and it will see all the files on all your disks and it will "magically" put it all together for you.

[itsrumsey]

The entire folder structure is not duplicated across single drives (what's the point?)

 

I think the point is evident from my previous post, unless I am not understanding something.

 

not as I think you imagine.

 

referring to my example, disk1 does not "know" track 2 is on disk 4m nor that track 3 is on disk 7.

 

However, they are all in the same directory structure.  i.e. /Music/Artist/Album/

 

unRAID just combines all items in /Music/Artist/Album/ into the same 'share' no matter where the actual files reside.

 

As has been mentioned, if your usb dies, get a new one, put your license file on the new one, boot up unRAID, and it will see all the files on all your disks and it will "magically" put it all together for you.

 

Thanks, this is exactly how I imagined it worked and just needed confirmation.  This gives me the confidence I was looking for that even in the event the USB and motherboard are destroyed, the system is hardware agnostic so as long as the drives are in good working order I can recreate the array with a brand new chipset / sata controller / usb boot device etc.  This is important to me as I've been burned by RAID failures in the past that were difficult or impossible to recover from.

[JustinChase]

The entire folder structure is not duplicated across single drives (what's the point?)

 

I think the point is evident from my previous post, unless I am not understanding something.

 

Yes, you seem to be not understanding something.

 

unRAID will handle your data just fine as long as you don't lose multiple disks simultaneously.

[Squid]

The entire folder structure is not duplicated across single drives (what's the point?)

 

I think the point is evident from my previous post, unless I am not understanding something.

I edited my post (think we cross posted) to make explain it better.

 

The folder structure for the files stored is there.  IE:  If you share is Movies, and you have a MovieA folder within it, you will see on that disk (if MovieA exists on that disk) /Movies/MovieA/moviefile

[RobJ]

Each drive has its own complete file system.  I believe that you are thinking of the unRAID User Shares file system, which is never saved, because it is a virtual file system created on the fly every time you start the array, and then destroyed when the array is stopped.  unRAID generates it from the individual file systems on the individual drives, essentially a merger of those folders selected to be User Shares.  Hope that helps?

[Squid]

 

unRAID will handle your data just fine as long as you don't lose multiple disks simultaneously.

And even if you do exceed the redundancy of the system, you will only lose the data stored on those particular drives, not the entire array (like a traditional RAID system)

[itsrumsey]

Another question:

 

Where is the data and configuration for Dockers stored?  Reconfiguring a Plex / Emby / CP / SB server from scratch can be daunting if you have a complex configuration. 

Can it be copied nightly to the array for back up purposes?

Are there various networking options for Dockers?

I assume the require the bridge to be enabled so they can be accessed over the network? 

Do they all share the same bridged IP address?  Is it different from the servers?

 

Each drive has its own complete file system.  I believe that you are thinking of the unRAID User Shares file system, which is never saved, because it is a virtual file system created on the fly every time you start the array, and then destroyed when the array is stopped.  unRAID generates it from the individual file systems on the individual drives, essentially a merger of those folders selected to be User Shares.  Hope that helps?

 

Yes, thank you.

[SSD]

Each disk has an autonomous file system. A user share is basically a root level directory on one or more disks. If you look at a user share, you will see a union of the files across all disks with that root level directory. Not rocket science or magical, but it works quite well. If you copy files to a user share, some configurations come into play that can help steer related files to the same physical disk. Besides for the OCD, this feature can prevent the need to spin up a disk in the middle of playing an album (or a movie depending on the capture format) which is more than annoying.

 

Hope this helps!

[itsrumsey]

Another question before the Docker one is answered:

 

I am not clear on cache drives.  A share that is cache protected cannot have more data written to it in a day than the size of available cache space.

What then, if I have a 512GB SSD as a cache drive, but a friend comes over and I discover I need to back up 1TB of data from his USB drive for him.

Additionally in this scenario lets assume I have already written 100GB to the share today, so there is data on the cache that his not yet been finalized on the array.

I can't simply disable cache for that share because I assume this will cause data loss for the 100GB on the cache that hasn't been written (unless I copy it over manually after disabling the cache?).

I suppose you can always create a new share that is not using the cache and move the data there directly, and slowly over several days move the data from one share to another never going above the cache size?

 

What is the optimal method to perform a transfer like this?

[Squid]

Another question:

 

Where is the data and configuration for Dockers stored?  Reconfiguring a Plex / Emby / CP / SB server from scratch can be daunting if you have a complex configuration. 

Can it be copied nightly to the array for back up purposes?

Are there various networking options for Dockers?

I assume the require the bridge to be enabled so they can be accessed over the network? 

Do they all share the same bridged IP address?  Is it different from the servers?

 

The data / configuration for the containers are stored separately from the docker image file (which holds the apps themselves).  They can be backed up to the array, but there can be some issues because those files are actively in use from the containers themselves.  You really have to stop the apps to back them up.  See here: http://lime-technology.com/forum/index.php?topic=36622.0  A better solution is to set up a cache pool for the cache drive (basically this turns the cache drive into a RAID 1)

 

Containers can be set to be either bridge or host (plex for instance runs as host - the others you listed run bridged).  When in bridge mode they do share the same IP as the server.

[Squid]

Another question before the Docker one is answered:

 

I am not clear on cache drives.  A share that is cache protected cannot have more data written to it in a day than the size of available cache space.

What then, if I have a 512GB SSD as a cache drive, but a friend comes over and I discover I need to back up 1TB of data from his USB drive for him.

Additionally in this scenario lets assume I have already written 100GB to the share today, so there is data on the cache that his not yet been finalized on the array.

I can't simply disable cache for that share because I assume this will cause data loss for the 100GB on the cache that hasn't been written (unless I copy it over manually after disabling the cache?).

I suppose you can always create a new share that is not using the cache and move the data there directly, and slowly over several days move the data from one share to another never going above the cache size?

 

What is the optimal method to perform a transfer like this?

You can at any time disable the cache of a share.  You will not lose the data.  Disabling the cache of a share just stops the system from writing to the cache drive.  If files on the cache drive are part of the share that is cache disabled, I believe that you will still be able to access them from the share.

 

If the cache drive fills up during writes, then subsequent writes will go directly to the array drives and bypass the cache drive.

[JustinChase]

a simple method would be to copy the data from the friends USB to an array disk directly.

 

with unRAID, you can specify user shares /mnt/user/backup/friends_data

 

or, you could specify disks directly /mnt/disk3/backup/friends_data

 

you could also trigger/run the mover script any time to force the 100GB onto the array.

 

I'm honestly not sure what happens if you try to copy more data than what will fit onto the cache; if it will stop copying, or just continue by putting it onto the array, or fail.  I just don't know, sorry.

[dgaschk]

If the cache fills during a write a write failure occurs due disk full. The cache will be bypassed when ever the Minimum Free Space setting exceeded. Make the Min. Free Space setting at least twice the size of the largest file anticipated.

[itsrumsey]

I decided to familiarize myself with a few unRAID features including preclear, so I used some spare 2TB drives I had around.  Any ideas why the read speed on the middle drive could be so low?  Also, what is generally considered a high temperature for drives?

 

[trurl]

I decided to familiarize myself with a few unRAID features including preclear, so I used some spare 2TB drives I had around.  Any ideas why the read speed on the middle drive could be so low?  Also, what is generally considered a high temperature for drives?

 

How is that drive connected? I would probably stop that preclear and get smart data for the drive. It may already be showing problems that would make the preclear a waste of time.

 

I have my disk temp alarm set at 45C.

[itsrumsey]

How is that drive connected? I would probably stop that preclear and get smart data for the drive. It may already be showing problems that would make the preclear a waste of time.

 

I'll be honest with you, I don't know how to make heads or tails of this report.  Can you take a look and see if anything appears unusual?

http://pastebin.com/Rn1SSN8y

 

edit:  Sorry I don't think the smart scan had completed in that last log.  Here is an update, it does seem to show some read errors: http://pastebin.com/Nf6JbicV

It isn't very detailed, it just states "read error", I guess that is enough (along with poor read rate) to assume the drive is toast?

[itimpi]

Both those reports show a huge number of pending sectors and uncorrectable errors.  That suggests to me that the drive is probably dying.  Those values would explain why the preclear was running very slowly.

 

You cannot safely use a drive with unRAID while it has a value of pending sectors that is anything other than 0.  It is 'possible' that writing zeroes to the drive might clear these but with that large a number I would not be hopeful.  You could try connecting the drive to a PC and running the manufacturers diagnostic software against it to see what it says.

[itsrumsey]

You cannot safely use a drive with unRAID while it has a value of pending sectors that is anything other than 0.

 

Thank you for the input.

 

I just read the FAQ on parity and I have a question on it.  Since parity bit on the parity drive is calculated by comparing the same bit across all disks, does that mean that any time I write anything to any drive that all other drives must spin up as well in order for the parity drive to modify the parity bits of the affected blocks?  And if not, then why not?

 

edit:  Nevermind I think I answered my own question.  I suppose it only needs to know the byte being written, its current value, and the value to be written.  If it is 0 -> 1 or 1 -> 0 the parity bit must be toggled.  So there is no need to spin up the other drives.

[SSD]

You cannot safely use a drive with unRAID while it has a value of pending sectors that is anything other than 0.

 

Thank you for the input.

 

I just read the FAQ on parity and I have a question on it.  Since parity bit on the parity drive is calculated by comparing the same bit across all disks, does that mean that any time I write anything to any drive that all other drives must spin up as well in order for the parity drive to modify the parity bits of the affected blocks?  And if not, then why not?

 

edit:  Nevermind I think I answered my own question.  I suppose it only needs to know the byte being written, its current value, and the value to be written.  If it is 0 -> 1 or 1 -> 0 the parity bit must be toggled.  So there is no need to spin up the other drives.

 

Correct. That is exactly the way it works.

[itsrumsey]

Correct. That is exactly the way it works.

 

So when we preclear a drive, is there any way for unRAID to know when the new precleared drive is added to an array that is it already all 0s and that no parity information needs updated?  Or does it need to perform a complete read of the of the drive (similar to the first step of preclear) before it can be utilized?

 

To expand on the question, what if you add a used drive to the system without preclearing it, but delete its partition table before putting it in your server?  What steps does unRAID take before the drive can be used?