gubbgnutten
-
Posts
377 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by gubbgnutten
-
-
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.
-
1
-
-
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
-
22 hours ago, Aloyloy said:
Seems like my copies start really quick when copying via windows after about 2 gigs I'm back to the standard drive speeds. Is that about normal? Is there any way to improve this further? I've love to be able to get at least 4gigs before the speed comes down.
The weird thing when I first got the thing I ran a test and could swear it copied like 9 gigs at full speed.There are NVMe drives that can sustain high speeds indefinitely and plenty that can handle four gigabyte.
What size and model do you have?
-
17 hours ago, JonathanM said:
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.
-
3 minutes ago, MurrayT said:
I dont know if this is what you are asking for, sorry Im so dumb on all this?
statemedianas-diagnostics-20220815-1428.zip 152.73 kB · 0 downloads
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!
-
1
-
-
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?
-
6 hours ago, Reyhn said:
After a couple of power shortages, I noticed that one of my four disks has a red X and says "Device is disabled, content emulated".
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.
-
2 hours ago, Mysticle31 said:
Newbie question I suppose... Why does my missing disk have data on it? I can see and access the data on it...? The drive is physically not there! I think I disabled it in the bios, but maybe I just took it out of the array. Is Unraid putting data on it?
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.
2 hours ago, Mysticle31 said:Disk 2 is showing 3.02 GB used... but it's empty?
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.
2 hours ago, Mysticle31 said:Background:
My drives are developing bad sectors and the array was full so moved all the data I never use to offline cold storage, and consolidated everything to disk3. The system is deciding to put stuff on disk1 which I removed.
Bonus question...
I built my rig in 2014 (I think) as a Desktop/Game system that saw Unraid use right away. It's an i5-4690K, 4th Gen with 32gb ram. I think the ram is the only thing keeping it alive, if I had a 16gb limit I might have replaced it already! The hardware is still fairly capable...I haven't ran into any limits with it running my dockers and a couple VMs. More cores could be nice...I could get an 8 core cpu used and run it some more...
Should I just update the drives or build a new server? I was hoping to get a couple more years out of the hardware I have... but I'd say that a couple of years from now too!
Now that it's an server, I'd like to build a smaller 4-5 external drive bay rig I can hide somewhere rather than my full tower.
If you don’t trust the drives, update them or retire them.
-
On 10/12/2020 at 4:08 PM, Toskache said:
During the test with dd:
sync; dd if=/dev/zero of=/mnt/cache/testfile.img bs=5G count=1; syncI realized, that the max. filesize for the cache is 2G. Is that correct?
Never seen anyone go for a block size of 5G before, that’s literally orders of magnitude larger than commonly seen...
How about a reasonable block size and increased count to match instead?
-
1
-
-
SMB is the way to go for modern Mac OS, yeah. Shouldn't really need any special configuration though.
Have you created any shares via the unraid ui?
-
2 hours ago, mkyb14 said:
Running mover, still has 200+GB on the drives.
Guess I was under the impression the Downloads folder once mover was run would clear out, but there are many older files and folders still in there. Is that normal? Am I missing a setup in my config?
Perfectly normal. It is simply not mover's responsibility to manage your completed downloads. Need another tool for that.
-
Just Windows displaying TiB while calling it TB...
1 TB = 1 000 000 000 000 bytes
1 TiB = 1 099 511 627 776 bytes
-
2 hours ago, squirrelslikenuts said:
Im 100% convinced its a samba issue... or the client system Im testing from.....
but the problem is that WRITES are saturating GbE ... so it can't be a network issue.
For completeness - How fast are writes to the parity protected array (for a share not using cache)?
When you do the write tests, what are you writing? (number of files, total size of data).
I would expect all writes over the network to occur at line speed until the RAM buffer on the server is full, and you do have plenty of RAM.
-
Try the exact path suggested earlier and post log from using that path.
-
25 minutes ago, opentoe said:
Amcrest told me to put it in like this
/sun/security/recordings
Listen to @bonienl, not to Amcrest.
-
No, the system clock should be the consistent actual time (UTC). That way a sensible operating system can easily compensate for time zones and daylight savings and derive the appropriate local time.
-
11 minutes ago, zin105 said:
I'm in UTC+01.00 Stockholm.
BIOS time is correct.
By correct, do you mean that it is set to UTC time?
And isn't Stockholm +2 compared to UTC due to daylight savings?
-
31 minutes ago, tunetyme said:
If you follow through the process, after you swap the new drive with all the files copied on it then you format the old RFS drive as XFS (formatting would destroy parity) or you could put another drive in that is already formated XFS (Like a larger drive) and repeat the process. Read the last several steps.
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.
-
1
-
-
1 minute ago, tunetyme said:
Nope I got those steps right. It was the warning that the parity drive would be erased. That is what started this discussion. See page 24 5th post down
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!
-
23 minutes ago, tunetyme said:
- I did steps 10 -16 where I became confused about parity. RobJ has updated this section as above to help with the confusion (see previous 2 pages).
- Step 16 was the start of the confusion about parity.
Step 16? Pretty sure your confusion about what was happening started no later than step 14.
-
35 minutes ago, tunetyme said:
I do understand how parity itself works and I understand how it works across drives basically odd or even. What I was trying to express is once I have made a duplicate set of files (rsync) on two different size disks with different formats (RFS v XFS) I am now able to remove the old disk and replace it with the new disc (same slot) and parity is still valid.
By removing the old disk did I just remove one of the bits being counted? By swapping the new disk with the old and removing the old disk (changing slots and removing the old disk completely) how is parity maintained? I have just swapped and removed one disks that was being counted in the odd even for each bit of data. I used to deal with parity issues when dealing with serial and parallel data communications. As I have tried to explain I tend to think in terms of an absolute address on each disk where a bit is counted as odd or even. any changes in the bit being counted or the quantity of bits being counted (number of disks) changes parity.
As I have said I need to think about what relative addressing means.
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).
-
11 minutes ago, tunetyme said:
OK, let me see if I can explain my dilemma in a different way.
Using bits
At address x on a 2TB drive RFS (not that the format is essential) =1 and address y = 0
I use rsync to copy the data to a 4TB drive xfs I am assuming that both formats use the same address scheme
you are saying that address x = 1 and address y = 0
I guess I am thinking like Windows where if I copy a file from drive a to drive b it also defragments the file when it is copied..
Are files ever fragmented under Linux?
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
-
24 minutes ago, deeks said:
Hi Gubbnutten, yes all zero bytes here...not good I guess. Any thoughts on how to resolve?
Cheers, Deeks
Should be safe to just delete them and restart the server.
-
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:
Now that it's an server, I'd like to build a smaller 4-5 external drive bay rig I can hide somewhere rather than my full tower. 
How do I move from NTFS to Unraid XFS?
in General Support
Posted
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.