gubbgnutten

Look at it as the perfect opportunity/excuse to get an external HDD for backup. 😁 Or if you are going the internal route, a disk to use as parity disk after the migration. Not the same as a backup, but it will cover for one failed disk.

Apologies in advance if this is not to your liking. Let’s just say that link aggregation is messy. I have it on my old server, a quad connection to a GS1900 or something like that. It took a lot of trial and error. I did it mostly for fun, I had the hardware, my homelab did not really benefit from it and I knew that beforehand. Please don’t take this the wrong way, but based on your questions it is not entirely obvious that you know if link aggregation will benefit you enough to warrant the trouble. Just switching to the Intel NIC from the Realtek NIC would be nice now that you have it. Why do you want link aggregation? Which problem/problems do you think it will solve? What will it improve? In the meantime, if you insist on going through with it — How about getting a free trial of some streaming service with content your partner is happy with to buy some time to tinker with the switch and your server? If you make a backup of the configuration you can go back to the current state of affairs with ease, no borking the whole thing for days. If you can’t get it working in 20 minutes, just revert to the previous configuration and use what you’ve learned to prepare for a new attempt some other time. If you can use GUI mode on the server things should go smoother during trial and error.

The Video Encode and Decode GPU Support Matrix is not listing decoding support for h.265 on GTX 970. https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new

There are NVMe drives that can sustain high speeds indefinitely and plenty that can handle four gigabyte. What size and model do you have?

Just keep in mind that this does virtually nothing to prevent the scenario described in the first post. Sure, the flash drive can’t be removed, but all the bad guy has to do is to bring a laptop and the passwords are toast.

Hey now, you’re not “so dumb on all this”. You’re learning, you’ve spotted a potential problem, you’re wise to ask about it, the question ended up in a very suitable place, and from the looks of it you correctly followed the given additional instruction. You’re going to do great! Unfortunately I’m not in front of a computer right now so I can’t take a closer look at the diagnostics. Hopefully someone else will get to it soon!

What motherboard/BIOS do you have? As for a workaround, can’t you just stick with UTC in the BIOS and adjust the wakeup time 8 hours instead?

That is not a problem with the file system, the disk needs to be rebuilt. I’m a bit rusty so I don’t dare provide instructions for that at the moment.

As @itimpi wrote better and more elaborated, the missing disk is emulated and the system continues to operate as if it were present. The system is indeed putting data on it, most likely you have high-water configured as the allocation method and that’s why writes are going to that disk. Move the data away from Disk 1 to the disk you want to keep (Disk 3) and follow the linked procedure to properly have Disk 1 (and why not Disk 2?) removed from the system. With the sizes of today’s drives, 3.02 GB is practically nothing. That amount of usage on an empty disk is typically just overhead related to the file system. If you don’t trust the drives, update them or retire them.

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.

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

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