While at it why not replace unformatted with something less?

unformatted simply means not-mounted

Not really! Well, it means that in theory, but in practice 4.5.3 does treat them as unformatted,

as it will try to format them if you press that unfortunate button.

 

So, we don't want to rename the format button, we want to get rid of it.

It shouldn't be such single button that applies to all disks at the same time.

 

 

Yes, on second thought it's better to get rid of it.  The way I deal with it is I format new drives in unMenu.  Then if a drive is labled unformatted in unRAID I know it's bogus.

Maybe it's possible to replace HTML in the same way you replaced the Restore button text.

You cannot quickly add a formatted disk to an unRAID array without having to completely re-calculate parity.  Formatting outside of unRAID's web-interface is not a good solution for most of us.

I formatted the disk in Unmenu, then stopped my array, added the new disk and started the array.  That does recalc parity.  But I never will format any of my data drives by accident.  

 

 

<!--  ^ifnot fsNumUnformatted=0^ -->

   <tr>

     <td class="cmd-state">Unformatted disk(s) present</td>

     <td class="cmd-action"><span class="button"><input type="submit" name="cmdFormat" value="Format"></span></td>

     <td class="cmd-comment"><strong>Format</strong> will create a file system in all unformatted disks.</td>

 

Change the button to a message and say whatever makes sense.  For me it would say read how to do this using unMenu.

I formatted the disk in Unmenu, then stopped my array, added the new disk and started the array.  

That does recalc parity.

And that is not desirable!  I'd much rather preclear the disk and let unRAID format it.

 

I formatted the disk in Unmenu, then stopped my array, added the new disk and started the array.  

That does recalc parity.

And that is not desirable!  I'd much rather preclear the disk and let unRAID format it.

 

 

You aren't a newbie.  You don't even need the manual anymore.  A newbie won't have a 15 drive server where it's a big problem to recalc parity.  It's better to be inconvienent than potentially destructive.

 

And I did preclear it first before formatting in unMenu. 

Ok, make the patch a safety patch.  So that users can opt out of having the format button disabled.  But advise newbies to have the patch.  That will at least force everyone to notice the issue around the Format button. 

It's better to be inconvienent than potentially destructive.

Queeg, you are not paying attention.  Rebuilding parity can be potentially destructive.  Not to mention time consumiing. 

You are without protection until it's done.  That is not desirable.

 

And I did preclear it first before formatting in unMenu. 

Which defeats the main purpose of preclearing the disk (other than exercising it)

 

Ok, make the patch a safety patch.

I am not making any patch.  We are just talking about what we want in stock unRAID.

 

Right

 

For stock unRIAD:

1.  Add drive pre-clearing for drives not assigned to the array

2.  Replace global "Format" button, replace with individual buttons.

3.  Rename "Restore" button to "Delete Parity and Disk Configuration Data"  Make description say existing parity and configuration will be deleted.  New configuration based on working and assigned disks will be created when array is next started.  Warn NOT to use button if a disk has failed and user intends to re-construct failed-disk contents onto a replacement disk.

It's not a big deal because everyone here seems to be an expert and I don't know if this has been mentioned somewhere before, but it'd be nice to have a simple button for "Back up my USB key configuration".  Not even sure where it would back up to (another USB key? a small section of the actual data array?) and how it would be restored, but you get the idea.

 

I just think a user shouldn't need to understand /mnt/flash/config or some such.

 

It's not a big deal because everyone here seems to be an expert and I don't know if this has been mentioned somewhere before, but it'd be nice to have a simple button for "Back up my USB key configuration".  Not even sure where it would back up to (another USB key? a small section of the actual data array?) and how it would be restored, but you get the idea.

 

I just think a user shouldn't need to understand /mnt/flash/config or some such.

 

Good idea.  Let me think about the best way to handle that in a universal way.

 

In the past I've cloned the entire drive at times, and I've also just copied the config folder at others.  I need more than the config folder, so I'll back-up the entire drive.

 

Joe L.

it'd be nice to have a simple button for "Back up my USB key configuration".  Not even sure where it would back up to...

Good idea.  Let me think about the best way to handle that in a universal way.

You could create some tiny hidden HPA partitions on random disks for such backups.

 

it'd be nice to have a simple button for "Back up my USB key configuration".  Not even sure where it would back up to...

Good idea.  Let me think about the best way to handle that in a universal way.

You could create some tiny hidden HPA partitions on random disks for such backups.

 

Actually, it is easier to keep the files visible.  No sense making it harder than needed when you are trying to recover from a failed drive.

 

Joe L.

I was just kidding!  HPA indeed!  That caused enough troubles already.

 

Actually, it is easier to keep the files visible.  No sense making it harder than needed when you are trying to recover from a failed drive.

 

Joe L.

 

Perhaps an unmenu package could be created for this one that uses rsync to copy /boot to disk1 every hour, day, etc.  Maybe make it editable like the .DS_Store unmenu package i created.

 

This is obviously just a temp fix but it would help at least.

Ok, ok, I'm paying attention now.  My secret wish is that enough of crashplan were installed that it would be simple to get it running on unRAID.  I mean, I never was able to get it installed.  Too many steps and all that.

Ok, ok, I'm paying attention now.  My secret wish is that enough of crashplan were installed that it would be simple to get it running on unRAID.  I mean, I never was able to get it installed.  Too many steps and all that.

 

I played around with creating an unmenu package manager package for this and it is just too much of a pain.  You need to walk through the install from the command line so your best bet is to follow the directions already outlined.

 

Whatever problems you had, take those to the Crashplan thread and I will try to answer them there.

Ok, ok, I'm paying attention now.  My secret wish is that enough of crashplan were installed that it would be simple to get it running on unRAID.  I mean, I never was able to get it installed.  Too many steps and all that.

 

crashplan shouldnt be that hard to install.. I'll be doing this in the next few days, so I can write up any steps taken..

Perhaps the shutdown process could keep the last 5 syslogs or something like that.  When people are confused they often reboot and don't save the syslog first.

i thought Tom had made it so you could have two flash keys installed.

There was something related to having the backup flashkey installed.

 

in my mind that's the way to go. rsync /boot to the other flash key wherever it may have been mounted.

Perhaps the shutdown process could keep the last 5 syslogs or something like that.  When people are confused they often reboot and don't save the syslog first.

 

The powerdown or rc.unraid script does this.

10 logs and deletes the oldest one.

It is also configurable on install.

 

 

fwiw, my hand is better, I'm back to work and I'll start updating the powerdown package soon!

 

Put a link to the unraid manual, forum or wiki on the main unRAID page.

fwiw, my hand is better, I'm back to work and I'll start updating the powerdown package soon!

I am so glad to hear that!    I mean your hand.

 

Respectfully, I'd go with the "Delete" wording.  You are really moving the system.dat file to system.old, so in effect you ARE deleting the old configuration and all records of the previous parity calculation.

 

It is strongly worded enough to make a new user think twice.  It is accurate (or close to being accurate)  The act of Starting the array will then create a new super.dat file with a new configuration.  It is actually how the new .config is stored, based on the then assigned and working disks.

 

... Tom ... even said once he is open to suggestions for re-wording, but apparently never liked any suggestions so far. (or never found time to make the change)

 

Joe L.

 

I'm willing to go along with the consensus, but have to admit I'm still uncomfortable with 'Delete' and 'Destroy'.  Plus, I don't think there is any chance that Tom will find either acceptable.  I thought I would take it in a new direction, with 'Create' or 'Create the array'.  The main problem with 'Restore' is the extra implications associated with 'restoring', as in a new user thinking, "if I Restore, it may restore all my data, fix all my problems, etc", and the temptation to a desperate user becomes irresistible.  In no way does 'Create' carry the same baggage.  An example is below.  I'm not sure the warning is even necessary with 'Create the Array', as this button is only of interest to those who are truly starting over or starting fresh.

 

 

[glow=grey,8,300]  Create the Array  [/glow]  Create the Array will establish a new array; all disks will appear as new and a parity build will be scheduled (if a parity disk is assigned), but data disk contents will not be affected.  WARNING!  DO NOT USE IF YOU INTEND TO RECONSTRUCT THE CONTENTS OF A FAILED DRIVE ONTO A REPLACEMENT, AS PRESSING THIS BUTTON IMMEDIATELY INVALIDATES ANY CURRENT PARITY INFORMATION.  WITHOUT PARITY, YOU CANNOT RECONSTRUCT THE CONTENTS OF DISKS.

 

 

It is not often that you see 'Create' and 'Destroy' suggested as names for the very same operation!

I still prefer

Delete Existing Parity Data and Disk Configuration

I think it is far less likely (in my opinion) to be pressed in a panic situation when a user is attempting to rebuild a failed disk.

 

Joe L.

[glow=grey,8,300]  Create the Array  [/glow]  Create the Array will establish a new array; all disks will appear as new and a parity build will be scheduled (if a parity disk is assigned), but data disk contents will not be affected.  WARNING!  DO NOT USE IF YOU INTEND TO RECONSTRUCT THE CONTENTS OF A FAILED DRIVE ONTO A REPLACEMENT, AS PRESSING THIS BUTTON IMMEDIATELY INVALIDATES ANY CURRENT PARITY INFORMATION.  WITHOUT PARITY, YOU CANNOT RECONSTRUCT THE CONTENTS OF DISKS.

I'd have to disagree on this one.  "Create the Array" just sounds way too cheerful and optimistic for the dark desperation it can bring!  

Oh, wait a moment... I just noticed a red ball next to one of the disks... Hold on, let me create an array with that disk real quick...

 

AAAAARGHH!!  

 

---

So far "Delete Parity" sounds the best to me.

 

It seems that the problem stems from trying to combine multiple actions into a single step.  Normally on a raid system you can create arrays and break arrays.  

If the button said Create Array when no array exists and Break Array when an array exists it would help.

 

I'm guessing it seemed easier to combine the two steps into one.  But it creates abiguity.