USB Thumb Drive Won't Appear in "Unassigned" Dropdown (6.0-beta15)


Recommended Posts

I'm setting up a server for a friend of mine and we decided to use a 64GB USB flash drive as his cache drive. 

 

We have the server set up and running just fine with 3x3TB drives (2 data, 1 parity), but I CANNOT get the USB drive to show up in the assignment list dropdown!

 

I know the drive works fine and is readable, as I can use the "Unassigned Devices" plugin to see the flash drive (shows up as device sdb) and mount it (ntfs formatted at the moment).  It also shows up with the correct size when doing "cat /proc/dev"

 

So why can't I get it to show up in the unassigned list?  If there's some built-in "you really shouldn't be assigning flash drives to the array" check, can I override it?

 

He has the "Basic" license for unRAID 6, so he should be able to use 4 devices (1 parity, 2 data, 1 cache), but I don't think that would be the issue anyway...even in trial mode you can "see" all available drives, even if you can't start the array with them assigned.

 

Thanks!

Link to comment

You can only assign IDE/SATA type devices.

I thought I had read about people using external USB drives as an UnRAID device, which would be the same thing. 

 

Is there some kind of override?  Or a way to fool unRAID into thinking it's a ATA/IDE device?  This seems like a weird limitation, especially when I want to use the device as a cache drive, not even in the array.

 

A USB device is good enough to *boot* from, but not use as a cache drive?

Link to comment

You can only assign IDE/SATA type devices.

I thought I had read about people using external USB drives as an UnRAID device, which would be the same thing. 

 

Is there some kind of override?  Or a way to fool unRAID into thinking it's a ATA/IDE device?  This seems like a weird limitation, especially when I want to use the device as a cache drive, not even in the array.

No
Link to comment

Any particular, you know, reason for such a limitation?  Rather limiting to have to assign a "for real" SATA device as a device...not everyone has a server with a million SATA ports/drive slots, and a SSD is essentially the same thing as a USB thumb drive, just on a different kind of bus (wear-leveling, etc not withstanding).

 

Linux doesn't care what's actually behind a given device designation, I just want to say "UnRAID!  Use device sdb as the cache device!".  Everything is a file to Linux anyway.

Link to comment

Unfortunately unRAID does not allow USB devices to be assigned and as far as I know there is no way to fool it.

 

It is not clear to me why you would even want a USB device as a cache drive.    If it was allowed you would almost certainly adversely affect performance compared to not having a cache drive at all.

 

Note that you CAN have a USB device that is not part of the array.  This would typically be used as a temporary device for copying files to/from the array.

Link to comment

Unfortunately unRAID does not allow USB devices to be assigned and as far as I know there is no way to fool it.

 

It is not clear to me why you would even want a USB device as a cache drive.    If it was allowed you would almost certainly adversely affect performance compared to not having a cache drive at all.

 

Note that you CAN have a USB device that is not part of the array.  This would typically be used as a temporary device for copying files to/from the array.

 

If I leave the device permanently mounted, can I use it to store app/plugin data? (sabnzbd, couchpotato, etc)

 

That's the main reason I want to use the USB drive, as storing that stuff on the boot USB drive is problematic at best.

 

Also, having a (slow) cache drive still allows you to have the parity drive (and possibly others) spun down pretty much all the time. And since 99% of the writing to the cache drive would be done without user intervention, I don't really care how long it takes to write to.

Link to comment

Although this might be technically possible, you would not want to do it as USB flash drives have limited lifetimes in terms of read/write cycles and are not suitable for this type of use.  Also I do not see how it would provide any advantages over using the boot drive which is just a USB flash drive after all.  I think at the end of the day you would be better off using one of the array data drives.

 

I am sure I am missing something?

Link to comment

Although this might be technically possible, you would not want to do it as USB flash drives have limited lifetimes in terms of read/write cycles and are not suitable for this type of use.  Also I do not see how it would provide any advantages over using the boot drive which is just a USB flash drive after all.  I think at the end of the day you would be better off using one of the array data drives.

 

I am sure I am missing something?

I thought that app/plugin data had to be accessible *outside* the array, meaning that it the array is down that the apps/plugins still need access to their configuration files.

 

Right?  Or am I wrong on that?

 

As for the boot drive, I'm run into some very weird issues where I'm not able to do a "chown" command on directories after creating them.  Most plugins run as the user "nobody", and I was unable to create directories using the nobody user OR take the directories I created as the root user and then chown them to nobody after creating them when using the boot drive.

Link to comment

I thought that app/plugin data had to be accessible *outside* the array, meaning that it the array is down that the apps/plugins still need access to their configuration files.

 

Right?  Or am I wrong on that?

Normally if the array is not active then normally all apps are stopped.  As such there is no reason why apps cannot live on an array drive.  The normal reason for using a cache drive is improved performance as writes have less overhead.    Note that a cache drive is not available either if the array is not active so this is not a solution to keeping apps running all the time.

 

It is possible you may have some special scenario where you want a drive to be active if the array is not started.  However if you do this you are not assigning the drives to unRAID and are thus not constrained by what the unRAID GUI allows and are managing them yourself.  You would then typically control such drives by adding appropriate entries to the 'go' and 'stop' files.  You would also be responsible for stopping /starting such apps as appropriate.

Link to comment

I thought that app/plugin data had to be accessible *outside* the array, meaning that it the array is down that the apps/plugins still need access to their configuration files.

 

Right?  Or am I wrong on that?

Normally if the array is not active then normally all apps are stopped.  As such there is no reason why apps cannot live on an array drive.  The normal reason for using a cache drive is improved performance as writes have less overhead.    Note that a cache drive is not available either if the array is not active so this is not a solution to keeping apps running all the time.

What happens when there are disks that are spun-down from not being read from, and then one of the apps suddenly requires a config/etc file from that drive?  Are the apps smart enough to wait for the file to become available?  Or is it best to make an "app" share and then tell unRAID not to split the directory, so that all config files are always on one physical disk?

Link to comment

I don't remember anyone ever asking for this before!  It does seem reasonable to post a feature request, although you will never see it recommended.  You don't want high write activity to a flash drive, which it will get, in traditional Cache drive usage.

Link to comment

I don't remember anyone ever asking for this before!  It does seem reasonable to post a feature request, although you will never see it recommended.  You don't want high write activity to a flash drive, which it will get, in traditional Cache drive usage.

It's OK, I was misunderstanding how the cache drive worked (I thought it was also available when the array was offline), AND I didn't understand that apps all shut down when the array is down.

 

Yeah, I know, weird request.  If it's insane and has no legit use, please ignore.  I'll just buy the flash drive off my friend (I told him to buy it, :)

Link to comment

What happens when there are disks that are spun-down from not being read from, and then one of the apps suddenly requires a config/etc file from that drive?  Are the apps smart enough to wait for the file to become available?  Or is it best to make an "app" share and then tell unRAID not to split the directory, so that all config files are always on one physical disk?

This is no different to the standard scenario under Linux when a drive is spun down.  In this respect unRAID is no different to any other Linux distro.  In practise the OS normally suspends the app in the read statement until it completes (or fails).

 

Having said that if you are going to put app related files onto a data disk then it would normally make sense to put all app related files on a single disk to so that is the only drive that tends to remain spun up, and also avoids any performance issues resulting from spin-up delays.  As such that would typically be done by having an apps share that is constrained to that drive.

 

What is not clear is what size array you are talking about where the number of SATA ports is the big constraint that you implied earlier.

Link to comment

It's OK, I was misunderstanding how the cache drive worked (I thought it was also available when the array was offline), AND I didn't understand that apps all shut down when the array is down.

There is a request in the Roadmap part of the forum to allow the cache drive to be kept online when the rest of the array is offline.    This is stated as being useful for the purpose of keeping apps and VMs running all the time.  This has been acknowledged as something that could well be of use but there is no timescale for providing this.  I can also see it might possibly be done by separating the concept of cache and apps drives - but until some sort of implementation is actually likely then any details would just be supposition.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.