gubbgnutten

By correct, do you mean that it is set to UTC time? And isn't Stockholm +2 compared to UTC due to daylight savings?

Well, let's agree to disagree. Or agree to agree. Or disagree to disagree. I'm actually not even sure what you so respectfully are disagreeing with... I'm not the one having a problem searching, and I am absolutely not saying that OR should be the default or that AND is not what most people would expect. What I am saying that the IPS folks made really really really bad decisions when designing the search interface. I don't see any easy overall fix, especially not one that would not break things for all users that have adapted to the current design. You keep promoting AND as the reasonable default search. I am not disputing that at all. But just imagine for a moment that both search fields had interpreted this is a test as an AND search and requiring explicit this OR is OR a OR test for OR search (almost never used anyway, right?). Then the two linked fields would have behaved consistently. I mean, there is no implicit OR in this is a test, if anything it would be an implicit AND, so why mess with + at all here? More fun with searches: Using the small search field to search for "this is a test" gets converted to "this+is+a+test" which unlike "this is a test" does not have any matches. All right, enough for now. Keep disagreeing, keep imagining I'm promoting OR, whatever makes you happy. I've taken up enough of people's time ranting about bad design decisions that are unlikely to get corrected.

No, you read the last several steps! Formatting does not destroy parity as it is done while the disk is assigned to the array and the array is started. Therefore the parity is updated to reflect the formatting. After all, formatting a disk means writing an empty filesystem to it. It is just as any other set of writes, parity does not care. It only cares about the raw bits. And no, you absolutely cannot put another drive in instead here. You have to use exactly the same set of drives to maintain parity.

It is a case of bad design. Really bad design. Two connected search fields should not behave completely different. Could you please enlighten me, where does it outright say that it is doing an OR search? All I can see on your picture is that it suggests searching for this OR is OR a OR test instead of the current text this is a test, not that it performed an OR search for the current text. This design clearly suggests that it did not just perform an OR search. Granted, clicking on the OR suggestion leads to a page where the search field is filled in with this is a test and familiar results, only differing in the url where search_and_or=or was appended. In this case it doesn't list this OR is OR a OR test as a suggestion anymore. Oh, and expanding the More search options in this case correctly has "Contain any of my search term words" checked. But what about the initial this is a test with removed +'s? Expanding More search options there had "Contain all of my search term words" checked... Probably only the tip of the iceberg, the IPS folks should have spent way more time thinking about how to design the search functionality+interface instead of rushing this piece of c...ode.

Silly me, I thought procedure was posted as a reply to my question about where you got the idea that parity was valid after completely removing a disk. The last bunch of posts about parity seem to be based on that misconception, rather than on the wording of step 16 (or the confusing web UI text)... So where did you get the idea that parity was still valid if a drive was removed? Well, I guess it doesn't really matter as long as it wasn't from a resource relating to this thread. Happy conversion and may your files live long and prosper!

Step 16? Pretty sure your confusion about what was happening started no later than step 14.

Sorry, where did you get the idea that parity remains valid if you remove a disk? Exactly what guide/procedure are you following? With single parity you can reorder disks and still maintain valid parity, but parity won't remain valid after removing a disk (unless you actually write zeros to the entire raw disk before removing it).

Words have apparently not made things less confusing, so I'll give a more practical example a stab. Let's pretend we have three drives, a 4 bit parity disk, a 2 bit data disk (Disk 1) and a 3 bit data disk (Disk 2): We start out with the following raw contents: Parity: 0110 Disk 1: 01 Disk 2: 001 The we copy a (pretend) one bit file from Disk 1 (second bit) to Disk 3 (different filesystem, ends up at other address on other disk), now we have: Parity: 1110 Disk 1: 01 Disk 2: 101 Replace the small Disk 1 with a fancy new 4 bit disk and rebuild. Extra space is filled with values calculated using parity disk and the other data disk, so parity remains valid: Parity: 1110 Disk 1: 0100 Disk 2: 101

When I click the search box a drop-down defaulting to "All Content" appears to the left of the text field. Changing it to "This Topic" limits the search to ... this topic! The new desk build search is a bit weird. Seems like it gets converted to new+desk+build. Replace that text on the search page with new desk build and your unRAID Desk Build will be in the search results... Edit: More specifically, if I enter new desk build in the small top right search box, I get sent to: https://forums.lime-technology.com/search/?type=all&q=new+desk+build Entering new desk build in the big search box on that page sends me to: https://forums.lime-technology.com/search/?&q=new%20desk%20build I would expect different search boxes to behave the same way, so absolutely a bug.

FAT32 with a label of UNRAID sounds right. How large is the Sandisk? Is it MBR or GPT?

Should not matter, it is the same web UI.

Nothing wrong with that, really, that's basically how I did it: Copy data to empty disk, verify checksums, format old disk, rinse, repeat...

How did you try to set the password? Using passwd won't stick, it has to be done through the web UI.

How about attaching the last diagnostics file FCP captured as well?

Would love that. Maybe should be extracted to a dedicated feature request?

And maybe also useful for running a correcting parity check on a small part of the array if a non-correcting check found errors.

Should be safe to just delete them and restart the server.

Only if you want to replace it with a smaller drive (or have the replacement in another slot).

Nope.

Well, "Cannot allocate memory" is certainly not good. Either you don't have enough memory, or something is misbehaving. Unfortunately syslog snippets are rarely useful... Could you try to grab diagnostics and attach it? Check the following post for more info:

Are you sure the URLs actually break? As long as the number does not change, it should still work even if the words from the title are different.

The parity is absolutely not valid if you removed a disk from the array.

Copying should work fine, only moves within the same mount point are problematic. On a related note - Don't mix disks and user shares unless you know exactly what you are doing, there are situations where you can lose data...

It is absolutely possible if they are mapped against multiple /mnt/user/[name of share] rather than one single /mnt/user.

At least the signatures are now limited in size and there is usually plenty of free space at the end of posts, so it wouldn't be as bad as it was in the old forum... Default to off is nice, though. Maybe that can help posters realize that the signature is not actually part of a post. Always fun to encounter old posts referencing a signature that does not match the post anymore.