Your Chance to Chime In

[brainbone]

My 2¢;

 

The write speed issue on some systems is an obvious known issue with 5.0 rc10.  As such, it shouldn't be released as final.  It is what it is,  a "release candidate" --  a candidate that has done what it should do; expose any outstanding issues before final release.

 

If the release of a final 5.0 with a fix for the write speed issue, or any other serious issue, is going to take while, it would be best to release an alternate version with a regressed kernel specifically for those with affected systems, and only as a stop-gap until a unified final.

 

There should be no rush to release.

[Dougy]

Unraid does not require more than 4g of ram to operate.  I'm not sure what plugin's do... but there is really no reason why unraid could not be limited to 4gb ram at this time.

[mejutty]

My 2¢;

 

The write speed issue on some systems is an obvious known issue with 5.0 rc10.  As such, it shouldn't be released as final.  It is what it is,  a "release candidate" --  a candidate that has done what it should do; expose any outstanding issues before final release.

 

If the release of a final 5.0 with a fix for the write speed issue, or any other serious issue, is going to take while, it would be best to release an alternate version with a regressed kernel specifically for those with affected systems, and only as a stop-gap until a unified final.

 

There should be no rush to release.

 

4.7 was a final and how many pieces of hardware does that not work with??  If the underlying systems only supports 4gb of ram and there are slow writes on some hardware with more than 4gb of ram that resolves with only then having 4gb of ram then I don't see the issue, it's not a supported configuration.  If it was 64bit or when 64bit goes rc and it didn't work then you need to re-evaluate.  At some point you need to draw a line in the sand about hardware and hardware configurations that are expected to work.

[limetech]

3.  A bug where the MBR of disks is overwritten with whatever the current "preference" might be if the config/super.dat file is missing and re-created on next start of array. (if the flash drive dies, or someone deletes everything on it and reloads unRAID) this bug has bitten quite a few people on 4.7 making their disks appear unformatted.  Some have lost data with this bug. 

Still unfixed as far as I know.  There is one open thread with a user on 5.0-rc8a with a similar issue where the file system on several 2TB drives was overwritten with GPT partitions usually reserved for 2.2TB and above.  This has not been mentioned in any release notes as being fixed.  I've no idea if it exists in rc10, but I do not want to experiment with my working array. 

 

Please point me to a thread that illustrates this bug.  In looking at the code, both in 4.7 and 5.0, I don't see how this can happen (that a partition layout previously written by unRaid can be re-written with a different layout by unRaid as a result of losing the array super.dat file, or any other means).  The exception to this is if a "factory erased", i.e., "pre-cleared" signature is present, then the partition layout is re-written, but just to clear the "factory erased" signature, other info such as starting partition 1 on sector 63 or 64 is not overridden.

 

The thread is here http://lime-technology.com/forum/index.php?topic=25132.0

 

This does not look like what you describe above.  Not sure how he got into that state.  The "EFI PART" string in sector 1 could be left over from some other system.  unRaid determines what kind of partition layout to set up based on the reported size of the disk using a BLKGETSIZE64 ioctl() call.  This returns the size of the disk in bytes (a 64-bit integer).  The sector count is then determined by dividing this number by 512.  If the sector count is <= FFFFFFFF then we use MBR, otherwise we use GPT.  So I don't see how a unRaid can write a GPT-style partition layout with a drive 2TB or smaller.  For an MBR partition layout, only sector 0 is written; sectors 1..62 (or 1..63) are not written at all, even if unRaid is doing a "clear".

[lionelhutz]

Tom,

 

Joe isn't dreaming this stuff up. I've seen many threads where the user had good drives get partitioned wrong with a new flash or cleared and newly created flash. Do a forum search and you'll find many examples.

[limetech]

Tom,

 

Joe isn't dreaming this stuff up.

Of course wasn't implying that.

[Joe L.]

The threads illustrating this bug are here:

http://lime-technology.com/forum/index.php?topic=23246.0

http://lime-technology.com/forum/index.php?topic=16523.0

http://lime-technology.com/forum/index.php?topic=15791.0

 

There is a bug in 4.7. Something is re-writing the partition tables under circumstances when the flash drive is replaced on an existing array.

 

The most recent occurrence on 5.0rc8a is the first report on a 5.X release, but most users do not have a flash drive failure.  It is different only in that it appears a GPT file system structure was written to the disks overwriting the reiserfs superblock.  (additionally, 2 of the three disks involved were 2TB, so should have never had a GPT partition at all)

 

The person in this 5.0rc8a thread  http://lime-technology.com/forum/index.php?topic=25132.0 said the disks had all originally been precleared.  Therefore, nothing should be left over from another OS.  (he did add he was not sure of the preclear on a couple of disks since his Windows PC rebooted overnight)    His MBR partitioning was not changed, but the file-system superblock on them seemed to be overwritten with a GPT partition header after re-formatting the flash drive and re-installing unRAID.

 

This does not look like what you describe above.  Not sure how he got into that state.  The "EFI PART" string in sector 1 could be left over from some other system. 

I don't have any way to know how it ended up that way either.  Prior OS, or a disk controller or BIOS deciding to do as it wished.    It might turn out this 5.0rc8a  person's issue has nothing to do with the one from 4.7, but initial circumstances and symptoms led me to think there is a connection.

 

Joe L.

[Joe L.]

unRaid determines what kind of partition layout to set up based on the reported size of the disk using a BLKGETSIZE64 ioctl() call.  This returns the size of the disk in bytes (a 64-bit integer).  The sector count is then determined by dividing this number by 512.  If the sector count is <= FFFFFFFF then we use MBR, otherwise we use GPT.  So I don't see how a unRaid can write a GPT-style partition layout with a drive 2TB or smaller.  For an MBR partition layout, only sector 0 is written; sectors 1..62 (or 1..63) are not written at all, even if unRaid is doing a "clear".

Then odds are unRAID did not put the EFI PART strings in sector 1.    In any case, it appears something clobbered the reiserfs superblock as the ReIsEr2Fs strings in the superblock were gone.

 

Joe L.

[Joe L.]

Tom,

 

Joe isn't dreaming this stuff up.

Of course wasn't implying that.

I know... 

[PeterB]

The person in this 5.0rc8a thread  http://lime-technology.com/forum/index.php?topic=25132.0 said the disks had all originally been precleared.  Therefore, nothing should be left over from another OS.  (he did add he was not sure of the preclear on a couple of disks since his Windows PC rebooted overnight)    His MBR partitioning was not changed, but the file-system superblock on them seemed to be overwritten with a GPT partition header after re-formatting the flash drive and re-installing unRAID.

 

Joe, out of interest I've had a read through that thread.  What you report above does not tally exactly with what block134 first reported.

 

I have been having some problems the past few days with my server so I removed my plugins, did a chkdsk on my flash drive and re installed the server software on the flash drive.  The first thing I did was remove the plugins and do a reboot and after the reboot I had three disks show up as unformatted ...

 

First of all, he tells of 'some problems', but doesn't detail exactly what they were, and we don't know whether he performed any other actions prior to removing the plugins and rebooting.

 

Secondly, it would appear that the disks became unmountable before he re-installed the server software.  We aren't even told whether the flash drive was reformatted as the initial step of re-installing.

[dave_m]

Using RC10, I deleted super.dat after assigning disks to the array, as well as copying over the contents of the config directory from the install package.  Each time I rebooted the server there were no disks assigned to the array, but there were never any other problems. Whether the partitions started on sector 63 or 64 did not appear to matter. I tested it several different ways with drives less than 2TB, but wasn't able to reproduce the bug as described.

[PeterB]

What if one of the drives is >2.2TB ... ie, uses GUID partitioning?

[jaybee]

What if one of the drives is >2.2GB ... ie, uses GUID partitioning?

 

4.7 only had support for <2TB drives though which is where this problem was first experienced no?

[Lacehim]

Personally I think we need to work towards a final stable release (I'll let Tom decide on when he's happy it's stable), and put any further updates/fiddling into 5.1+

 

On a side shoot work on a 64-bit kernel as a separate project to see if it works first.

 

I've upgraded from 4.7 to 5.0RC10 last week, not out of choice, but because I desperately wanted to run Plex on my media server for my new LG TV.

 

I think the plugins, although still in the early stages are great and that a 5 Final will spur these projects on.

 

Tom, I'm not sure if your ready for this, but have you thought about utilising some of the clued up forum members to work on unraid?

[BLKMGK]

My first thought was "There's an RC10?!". :-) Hope it fixes something I think I'm seeing lol!

 

I'd say release please. 64bit is needed as the 32bit kernel gets less attention but it may bring about much more work, don't hold the release for that. R5 has so many new working features and works really well once tweaked - don't hold it back. Release and mention the bug clearly and the workaround if it works. Begin work on a 64bit version and communicate with us, we will gladly help test it for you. Communication helps a great deal, we're on your side Tom and want you to succeed!

 

I'll also say, those of us running crazy plugins and the kitchen sink need to recognize we're not in supported configs. We're going to see more issues and understand this...

[Jon]

I don't understand releasing it to final with a known issue like this.  If it were something more slight, then sure, but not this.

 

I don't mind waiting longer for a good final release.  Stamping it final now just seems more like a pacifier.

[Joe L.]

Using RC10, I deleted super.dat after assigning disks to the array, as well as copying over the contents of the config directory from the install package.  Each time I rebooted the server there were no disks assigned to the array, but there were never any other problems. Whether the partitions started on sector 63 or 64 did not appear to matter. I tested it several different ways with drives less than 2TB, but wasn't able to reproduce the bug as described.

That is good news indeed. 

[jumperalex]

Using RC10, I deleted super.dat after assigning disks to the array, as well as copying over the contents of the config directory from the install package.  Each time I rebooted the server there were no disks assigned to the array, but there were never any other problems. Whether the partitions started on sector 63 or 64 did not appear to matter. I tested it several different ways with drives less than 2TB, but wasn't able to reproduce the bug as described.

That is good news indeed.

 

Well ... isn't good news first replicating the problem in [not-RC10], then finding that the same steps do not replicate it in RC10?

[lionelhutz]

Using RC10, I deleted super.dat after assigning disks to the array, as well as copying over the contents of the config directory from the install package.  Each time I rebooted the server there were no disks assigned to the array, but there were never any other problems. Whether the partitions started on sector 63 or 64 did not appear to matter. I tested it several different ways with drives less than 2TB, but wasn't able to reproduce the bug as described.

That is good news indeed.

 

Well ... isn't good news first replicating the problem in [not-RC10], then finding that the same steps do not replicate it in RC10?

 

That was my first thought. Just not having it happen on one system doesn't prove it won't happen. Start with 4.7. If you find a combination that creates the failure then repeat the exact same test in RC10.

 

[dlandon]

I suggest making 5.0 final and specifying which hardware has compatibility issues (slow write, etc).  The advantages of 5.0 being final outweigh the issues with slow writes that some might experience.  Finalizing 5.0 will let those developing/supporting plug-ins complete them and work out the kinks.  Continuing the "creeping elegance" will only frustrate Tom and the unRaid community.  i.e. one issue is solved and then another pops up.  Oh yea, can we just add one more feature.  It could be an endless cycle.

[woolooloo]

Hi Tom,

 

I have been using 4.7 on my old rig for just over 2 years.

 

I built it as a copy of your default build at the time (Supermicro C2SEE), using parts available to Australia.

 

I would love to see a 5.0 final for the following reasons:

1) Support for 3Tb drives

This is important as the drives are cost effective, and it will eliminate expensive upgrade path (bigger PSU, bigger case, additional SATA = >$300)

 

2) Updated SMB (v2)

There have been considerable updates to SMB on Windows clients (eg Win8), but also from my media players (Openelec). Newer SMB support should mean faster read performance.

 

3) Chasing your tail

It seems that unRaid development has been chasing its tail for a while now. Upgrade the kernal to support x... then y breaks. This could go on forever.

 

4) Could you please summarise the "Slow write" issue? I started reading the 12 page thread, but it might be easier for everyone if it was easily quantified about who might be effected.

 

I would be happy to see V5, then see v5.1beta's with experimental kernals for those with performance issues or who would like to be on the bleeding edge.

 

I'm with you, I need 3GB support. I'm tired of buying additional drives when I've got 3GB drives already in the array with 1/3 of their space being unutilized. Plus, the longer this goes on and the more 3GB drives I use as 2GB drives, the more time it is going to take me to convert them all to 3GB drives to recover the lost space. I'm really not looking forward to that as it is.

 

Look, the people with that hardware or thinking of buying that hardware are already SOL and need to wait for a solution. Why make all of us wait? Release 5.0 with a disclaimer for the known issue please.

[spasszeit]

Hi Tom,

 

I have been using 4.7 on my old rig for just over 2 years.

 

I built it as a copy of your default build at the time (Supermicro C2SEE), using parts available to Australia.

 

I would love to see a 5.0 final for the following reasons:

1) Support for 3Tb drives

This is important as the drives are cost effective, and it will eliminate expensive upgrade path (bigger PSU, bigger case, additional SATA = >$300)

 

2) Updated SMB (v2)

There have been considerable updates to SMB on Windows clients (eg Win8), but also from my media players (Openelec). Newer SMB support should mean faster read performance.

 

3) Chasing your tail

It seems that unRaid development has been chasing its tail for a while now. Upgrade the kernal to support x... then y breaks. This could go on forever.

 

4) Could you please summarise the "Slow write" issue? I started reading the 12 page thread, but it might be easier for everyone if it was easily quantified about who might be effected.

 

I would be happy to see V5, then see v5.1beta's with experimental kernals for those with performance issues or who would like to be on the bleeding edge.

 

I'm with you, I need 3GB support. I'm tired of buying additional drives when I've got 3GB drives already in the array with 1/3 of their space being unutilized. Plus, the longer this goes on and the more 3GB drives I use as 2GB drives, the more time it is going to take me to convert them all to 3GB drives to recover the lost space. I'm really not looking forward to that as it is.

 

Look, the people with that hardware or thinking of buying that hardware are already SOL and need to wait for a solution. Why make all of us wait? Release 5.0 with a disclaimer for the known issue please.

 

3GB drives are fully supported in v4.7, as well as 4GB, and all drives up to 2000GB;-)

 

[neilt0]

TB, not GB! 

[technojunkie]

I'm one of the users who has stuck with 4.7 because I don't want to deal with the headache of beta issues. The WAF is still closely tied to uptime, reliability and usability.

 

The if the slow write issue is the only real game-breaker, and it's hit or miss; I say go ahead and release. If I run into the same issue when I upgrade, I'll revert to 4.7 no harm done.

[aptalca]

I say release, and have a disclaimer about non-compatible hardware

 

I mean unraid really does not *have to* work with all hardware

 

Didn't the other stable releases have compatibility lists and disclaimers as well?? I remember picking my mobo based on those lists and I avoided the boards with that specific ethernet controller that caused issues (Realtek 8111E)

 

See following: http://lime-technology.com/wiki/index.php/Hardware_Compatibility