tenchiken

joined 2 years ago
MODERATOR OF
[–] tenchiken@lemmy.dbzer0.com 11 points 2 weeks ago (3 children)

If it's not from the sweeping fields of Russia, it's only sparkling gulag.

[–] tenchiken@lemmy.dbzer0.com 0 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

The ability to manipulate matter at the subatomic level, with explicit accuracy and knowledge.

From there, I'd be able to pretty much solve any problem.

Enemy? Turn them to goo. Or brain hemorrhage. Or invert their genitals. Explosive toenails. Literally shit for brains. Boobs on the head.

Sick? Convert the virus to vitamins or something.

Hungry? Food.

Solve pollution.

Aging? Reverse oxidants etc...

[–] tenchiken@lemmy.dbzer0.com 6 points 3 weeks ago

A twist: the birthday was OP, and the present was to himself via girlfriend later that night.

[–] tenchiken@lemmy.dbzer0.com 1 points 3 weeks ago (1 children)

Awesome, so that's good news. Disks probably just fine.

My next thoughts are on the service itself then... Your service providing the share might be getting throttled or not getting direct access to kernel hooks for performance.

Simplest test I would think is set up Samba or NFS in the host itself, not a container. Try a large transfer there. If speed isn't an issue that way, then something at the container level is hindering you.

[–] tenchiken@lemmy.dbzer0.com 3 points 3 weeks ago (3 children)

Hmm, at a glance those all look to be CMR.

To rule this out ideally, a tool like iostat (part of sysstat tools) can help. While moving data, and with the problem happening, if you run something like "iostat 1 -mx" and watch for a bit, you might be able to find an outlier or see evidence of if the drives are overloaded or of data is queueing up etc.

Notably watch the %util on the right side.

https://www.golinuxcloud.com/iostat-command-in-linux/ can help here a bit.

The %util is how busy the communication to the drive is.. if maxed out, but the written per second is junk, then you may have a single bad disk. If many are doing it, you may have a design issue.

If %util doesn't stay pegged, and you just see small bursts, then you know the disks are NOT the issue and can then focus on more complex diagnosis with networking etc.

[–] tenchiken@lemmy.dbzer0.com 6 points 3 weeks ago (6 children)

What drives? If they are shingled, your performance will be terrible and the array runs a high risk of failing.

CMR is the way to go.

SMR behavior is about like what you describe... Fast until the drive cache is filled then plummets to nothing.

[–] tenchiken@lemmy.dbzer0.com 1 points 3 weeks ago

The story so far: In the beginning the Web was created. This has made a lot of people very angry and been widely regarded as a bad move.

[–] tenchiken@lemmy.dbzer0.com 2 points 1 month ago (1 children)
[–] tenchiken@lemmy.dbzer0.com 1 points 3 months ago

OP, check if the default format of your pictures is HEIF (Samsung I know does this). It can be found under the camera app settings typically.

Mastodon and some other servers choke on this format frequently unless all the backend code is updated... Not sure about the Lemmy servers yet. It drove me nuts for days until a log item in my mastodon server I run brought my attention to it.

Unfortunately if you confirm this, you can't fix it client side except to convert your pictures first or disable that format for saving.

view more: ‹ prev next ›