First thing I learned is I failed miserably at communicating what problem I was trying to solve in my original post. I'll try to restate it here, lets see if it's an improvement:

 

PROBLEM: USB Flash drives continue to grow in capacity, while unRAID's required space is small by comparison. My problem is that free space is wasted, because no valuable purpose it can serve has been identified. My first unRAID USB flash drive many years ago was 2GB. Then came more at  4GB, 16GB, and my latest is 128GB. By comparison, unRAID's USB drive capacity requirement is simply 1GB. With a 128GB drive, is there a purpose the other 127GB could serve?

 

INSPIRATION: @limetech posted a new USB creator tool allowed >32GB flash drives. I tried it, I love the tool. It got me thinking though "what is possible with all this extra space on the unRAID usb flash drive?"

 

CONSTRAINTS: There are some constraints in this quest that limit the potential applications of use. USB has limited I/O speed. FAT32 has limitations. Of all of these constraints, which could be mitigated sufficiently (not optimally!) to be viable in that 127GB of otherwise wasted space?

 

THE ELEPHANT IN THE ROOM: Disk writes effecting lifespan of USB Flash Drive. This is effectively a blocker for many use cases. Consider that this research effort ignored the elephant, simply to find what was possible if lifespan didn't matter, or if writes could be effectively mitigated or are simply not a risk. 

 

EXPLORED APPLICATIONS OF USE: Not many viable opportunities to pick from. As is quite clear to many who posted here, using USB is not worth exploring for this simply due to all the constraints involved, and there are better options available. Anything I would likely discover in this endeavor was going to be a really narrow use case, because far superior options would be preferable to whatever application of use I'd discovered. I picked Docker.

WHY DOCKER?: Simply put, the docker.img can be small enough in size that it's not useless because of USB I/O speed. If required Docker.img could be smaller than 4GB if needed to work within FAT32 limits. As for /appdata, there are plenty of applications that run in containers that do not create a significant amount of  that would effect lifespan significantly. For apps that are write or I/O intensive, those can be mitigated with using the RAM. There are certain applications that simply not effectively mitigated though, so again it depends what docker container apps you are planning to run in this scenario.

 

VIABLE SOLUTION FOUND:

I used a 128GB Sandisk Cruzer Fit.

 

On my Windows PC, I created a 1GB partiion in which UNRAID was installed  I then moved the USB to and tested that it worked.

 

Then using putty to ssh into my new UNRAID server. From the command line I used the fdisk to create a second XFS partition that was 127GB. Next I formated it as XFS and mounted it as /mnt/disks/usb

 

I created the following directories:

/mnt/disks/usb/docker/img

/mnt/disks/usb/docker/appdata

 

Next I used chown and chmod to set appropriate ownership and permissions

 

Next I moved to the UNRAID GUI. This new mounted file-system will appear in the UNRAID's Settings > Docker Settings within the directory menus or can also simply enter the path into the field. I set the docker image filesize to 15GB and pointed it at the docker/img path, and likewise set the appdata path.

 

Started Array and installed Community Applications. Everything works as expected  Research effort a success!

 

WHAT NEXT? Nothing planned. There is potential here should others see a need to explore this as USB drives continue to grow in capacity and one wishes to utilize that space.

Edited September 29, 20178 yr by Lev

Well done Lev, impressed by how much enthusiasm and time you've put into this!

Yes this is possible and UI design specifically allows for this.  If you are really intent on using your USB boot flash, maybe try out f2fs instead of xfs?

 

But in general we are against this because your license key file is tied to your USB flash device.  In fact we are trying to go the other direction: get everything that's read/write off the USB flash except the most basic/critical config data.

 

Sure it seems "wasteful" to have hundreds of Gigs of unused space, but this is only the case because the devices are so cheap.

 

On the other hand, the size of unRAID OS download is continuing to grow.  If you want to keep the current release along with a couple 'previous' releases, you have to ensure enough space is available in partition 1 to accommodate.

 

To answer another question, why does chbmb have to maintain the "dvb  edition"? Well adding all the required drivers greatly increases the download size (and time to download) and we don't want to require the large majority of users to have to download a great deal of stuff they will never use.  Also presents problems having the GPU drivers present for those who want to use GPU pass through to VM's because once the host 'binds' a device, in our experience, unbinding and then assigning to a VM is not always reliable.  To solve this we have to implement some kind of module blacklisting UI - again a pain-in-the-neck for majority of users.

 

Where this is going is that we want to implement "editions" of each release, where you can select what you need.  For example, maybe you don't use the console-GUI, ok you could select a download version that omits this.  Maybe you want the dvb-edition, ok you could select that.  Astute observers might recognize that the Flash Creator tool provides the foundation on which we could add this capability.

16 minutes ago, limetech said:

Astute observers might recognize that the Flash Creator tool provides the foundation on which we could add this capability.

Why not to add this on GUI? at first, all you download a minimum version and then select additional features if you want. just a quick reboot and you are done    

6 hours ago, limetech said:

Sure it seems "wasteful" to have hundreds of Gigs of unused space, but this is only the case because the devices are so cheap.

 

True. Wasteful is the wrong word. Let me try restating it differently even if it doesn't change any conclusions:

 

As time continues to progress forward... USB flashdrives will continue to grow in capacity (and be cheaper!) at a order of magnitudes ratio against the size requirements of unRAID. I/O speed from USB 2.0, 3.0 and 3.1 improves. Write endurance will improve.

 

There's a deeper more personal reason why I did this though. I never could have imagined six years ago when I got my first pro license, that UNRAID would stand that test of time. SIX YEARS, 2011!  Look at how many other software technologies have come and gone since then. I don't see any competitive threat, or technology that serves my needs better. UNRAID has evolved over time to do very creative new things (i.e. Docker, VM, Dual Partiy, XFS, Plugins, community support) so many things I can't even do the list justice. Knowing that, I expect UNRAID will continue to serve my needs for a long future ahead. So why not get creative, see what's possible whether it's trying something like this or the other effort I'm researching at the moment to improve write speed to the array. That's afar more complex research effort so wanted to try this USB one firstfirst.

The only competing technology has always been ZFS and yet, it's not similar to unRAID's RAID4 implementation.

 

ZFS realtime checksum is a plus, but you still need to scrub periodically (similar to parity check) and vdevs handling is not on par with unRAID's do whatever you want as long as parity disk is big enough, even better if you have another parity disk to do dual.

 

6 hours ago, Lev said:

I/O speed from USB 2.0, 3.0 and 3.1 improves. Write endurance will improve.

 

In my experience with selling a lot of Kingston flash drives it's the opposite, older USB 2.0 are slower but many times more reliable than the newer USB 3.0.

Wow this thread really brought out many longtime All-Stars I've come to respect over the years. Quite humbling, thanks to all of you commenting. 

 

With this effort complete, I hope to re-edit my original post in the weeks ahead to make it more easy to consume for searching and if anyone tries to find this in the future.

 

In parallel I've been busy at work exploring a different research effort on adding some creative solutions to write performance. https://forums.lime-technology.com/topic/59686-methods-to-improve-write-operations-to-unraid/

 

In this effort I'm exploring whats possible by applying 'Lateral Thinking' methodology https://en.wikipedia.org/wiki/Lateral_thinking

 

 

 

Edited September 30, 20178 yr by Lev

On 9/29/2017 at 9:24 AM, limetech said:

maybe try out f2fs instead of xfs?

 

@limetech I've been doing some reading on f2fs, thanks for pointing me that way. I'm not sure how be to capture and make visible the benefits by switching to f2fs from xfs. So perhaps this is worth a spin off of this thread and into a new research effort.

 

@dlandon @johnnie.black @SSD @itimpi @Frank1940 since I've noticed the many of you are into these types of file-system / IO performance topics

 

What I propose below is simple a place to start the conversation. So please comment or suggest otherwise, I need input in order to determine if this research is of value and how to test for it.

 

RESEARCH GOAL: Better understanding of F2FS and its benefits compared to XFS and BRTFS in use cases that are common in UNRAID , exploring and measuring test results to see if F2FS should  ever be supported as a cache drive or UD file-system.

 

TESTS: Are there tests or operations where I could measure the difference?I'd need some details on what the tests would be and the expected results.

 

TEST ENVIRONMENT:

I've got two different servers I could perform these tests depending on what might best show some results:

• SERVER A) As detailed on this thread, I'll perform TBD tests on the USB 128GB SanDisk Cruizer Fit on XFS and then reformat to F2FS and rerun the same tests. Gather data, report out.
• SERVER B) Perform the same tests on a 2TB Cruical MX300 SSD. It's on a different server and it's presently assigned as a brtfs cache drive that's not doing anything so I could run tests before I unassigned it and then reformat it as F2FS and repeat tests.

Thoughts?

 

On 9/29/2017 at 9:24 AM, limetech said:

maybe try out f2fs instead of xfs?

 

@limetech I'm having trouble finding the command... make.f2fs , mkfs -t f2fs  and then when I check supported filesystem types, I don't see it in the list. What am I missing?

 

 

# cat /proc/filesystems | grep -v nodev
        squashfs
        vfat
        msdos
        iso9660
        fuseblk
        udf
        btrfs
        xfs
 

Presumably it isn't included in unRAID. Why would it be? A lot of unnecessary stuff it stripped out to keep it light. If you want to experiment with it you'll have to download it from the Slackware repo and install it yourself.

It's supposed to be included since v6.3.2:

 

- added F2FS support (user request):
  - CONFIG_F2FS_FS: F2FS filesystem support
  - CONFIG_F2FS_FS_XATTR: F2FS extended attributes
  - CONFIG_F2FS_FS_POSIX_ACL: F2FS Access Control Lists

It's supposed to be included since v6.3.2:
 

- added F2FS support (user request):  - CONFIG_F2FS_FS: F2FS filesystem support  - CONFIG_F2FS_FS_XATTR: F2FS extended attributes  - CONFIG_F2FS_FS_POSIX_ACL: F2FS Access Control Lists

The filesystem may be supported but f2fs-tools is not included and I don't see a prebuilt slackware package anywhere. There was a slackbuild for android-tools that may include f2fs-tools.

Thanks, @johnnie.black , @dmacias and @John_M, I'll find another computer to format the partition to F2FS, that should be easy enough. Then I presume it'll mount based on that v6.3.2 change. I'll post when I know more.