Settings never save. Read only filesystem

[bmfrosty]

root@Tower:/boot/config# touch blah.txt

touch: cannot touch ‘blah.txt’: Read-only file system

 

Just setting this up for the first time on this server.  Trying to do 24 SSDs.  I have 19 of them working (either the LSI card or expander or possibly one of the backplane slots is giving me a problem), but my settings never seem to save.  I went ahead and gave root a password, and ssh'd in, and found that I couldn't save to the USB drive. I get the error as above.

 

I'm digging through dmesg next.  Any thoughts?

[bmfrosty]

And solved by umounting and remounting the USB drive.  Weird stuff.

[trurl]

Put the flash in your PC and run checkdisk.

[limetech]

Trying to do 24 SSDs.

 

We have not tested SSD's as part of the unRaid array.  There might be an issue related to TRIM - if the SSD does a silent TRIM or is given an TRIM/ERASE command, this could very well invalidate parity.  But, like I said, we haven't tested this.

[jumperalex]

I'm about 99% sure someone on the forums (weebotech) once did a test with an array of SSD's ... made us all rather wooly at how fast it was writing directly to the array   I don't know if he had any trim going on (probably not since rfs doesn't support) but i do think the drives had decent built in garbage collection.

[BRiT]

Trim should not impact the external facing filesystem or data. It was strictly an internal only housekeeping item for the drive to manage empty write blocks. But they kept on adjusting how things work between the drive and the OS that I can't be 100% certain it doesn't do bad things from a data parity perspective.

 

I suggest for the curious to read up on SSD and what happens behind the scenes to get an appreciation for how it's handled from the technology perspective. Anandtech and TechReport have had some great articles on this over the past 4 years or more.

[jumperalex]

Of course what I'm about to say can be trumped by, "yeah well they did it anyway" but ...

 

I'd say the chances of an SSD ever presenting differently to the OS after TRIM is slim to none.  Otherwise it would cause many backup programs to go ape sh!t during incremental/differential backups.  Suddenly blocks that are actually completely unchanged but for location are being backed up wasting storage space for no good reason.

 

A corollary/ anecdote to that is defrag and backups.  For the longest time I couldn't figure out why Acronis was generating huge differential backups until I figured out it was because the windows scheduled defrag on my HDD was causing Acronis to see the moved blocks as changes to the partitions and it acted accordingly; mind you file metadata is unchanged.  After I reduced defrag to once a month and scheduled my differential / full cycles such that the defrag happened just before the next full backup, my differential backups shrank tremendously!!!  Like orders of magnitude and in sync with the amount of data change I know was actually happening.

 

That is exactly what would happen if TRIM didn't hide the internal shuffling from the OS.

 

Easy test of course, set up a two disk array, fill with some data, then delete it, force an fstrim and check parity. 

[bmfrosty]

Put the flash in your PC and run checkdisk.

 

That seems to be the problem.  Tried unmounting it, running fsck.msdos on it and found the dirty bit.  Changes there don't seem to stick.  I'm starting to suspect a bad usb flash module.  I'm going to hit the hardware forum and find the recommended module, and then order it on Amazon.

[bmfrosty]

If anyone's interested in what box I'm using for this, here it is:

 

http://www.supermicro.com/products/chassis/2U/216/SC216E1-R900LP.cfm

http://www.supermicro.com/products/motherboard/QPI/5500/X8DTH-6.cfm

 

32gig of ram. 

 

Two of these:

 

http://ark.intel.com/products/47925/Intel-Xeon-Processor-E5620-(12M-Cache-2_40-GHz-5_86-GTs-Intel-QPI)

 

24 Intel Drives.  Although, I'm pretty sure one's bad.  Will push forward on Friday when I'm next in the cage.