Snapraid 10.x vs 11.x

[hidegh]

What are the breaking changes?

Start:
Elucidate does execute the snapraid exe via arguments.
Were those arguments changed between versions (IMO: not, it seems to work - if yes, which ones)

Config:

• One big diff. is in the config file and the data disk naming.
• Based on snapraid 11.x samples names are d1..dN (which elucidate somehow does not like - IMO those names can be anything, but the order does matter).
• Elucidate works with names d0..dn-1.
• So changing the names naming (not hardpoints) should do the trick.

If elucidate will focus just on some values and will be able to alter only that potion of the config file, it could become more stable. Actually for those people who have even bigger aversion to text config files than me, the basic setup GUI will do.

The only extra functions i've used: autosave 250.

Btw. any date when 11.x changes will be analyzed and implemented?

[Smurf-IV]

Thanks for the analysis.
I am still working on KryptonComponents which I will use as the base theming for Elucidate etc.
I still have a few Extension features to add, complete testing and the existing help transfer.

[hidegh]

Hi, got into further details of the config codes you got, so i'd probably refactor it so that it honours existing config structure, instead of rewriting, and the code would be something like that:

1. read confign in memory
2. apply our properties one by one (parity, q-parity, content, disk, ...)
3. identify 1st occurence of the given property - find line
4. if no 1st occurence, we need to write a new block (code already inside ConfigFileHelper.cs)
5. if first occurence exists: remove all occurence, insert our config at 1st occurence (still working with lines or array of strings)
6. repeat from 3) until all supported props are processed

The (InMemory)ConfigFileHelper would possibly have methods:

• CreateExcludeBlockWithCommets(excludeConfig)
• InsertExcludeBlock(line to insert after, excludeConfig)
• ...and so on for each property

Also since we manage the thjings in memory, I'd possibly have an InMemoryConfigFile (array of strings) and would decouple writing.

To minimize changes, possibly the CurrentConfigFileHelper public methods should be kept and the necessary changes done just by calling the InMemoryConfigFile methods...

Also it's likely that from a given point only breaking changes in SnapRAID should make necessary to do changes in Elucidate...(this config thing is the one that should help to achieve that)...

[hidegh]

MAJOR CHANGE:
snapraid 11.x uses data name path
while
snapraid 10.x uses disk name path

This is the reason why a new config (manually created) is not recognized via Elucidate.

But according snapraid documents: In the configuration file 'data' is now a synonymous of 'disk' as ov ver. 10.0 - so we still might use DISK in the config...but this might change in the future, so it'd be wise to switch to "data".

Also to note:

• the name and mount point association is relevant for parity, do not change it!
• maybe SnapRaid.conf should be the default config (see snapraid 11.x defaults)

[hidegh]

TODO (summary of my notes above):

1. MEDIUM RIORITY make sure that inside configuring snapraid data disks, we use data keyword instead of disk
2. HIGH PRIORITY when loading data disks, the line has following structure: data name path - the name value has to be preserved, we can't change it to d0, d1, ... dN
3. LOW PRIORITY if we configure a new disk, add the ability to give any name to a data disk (also make sure there's a warning that changing data name results in parity data to become invalid and a new full sync is needed then)

[Smurf-IV]

#32