Re: [gentoo-user] NAS and replacing with larger drives

[Frank Steinmetzger <Warp_7@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 3951 bytes --]

Am Sun, Dec 18, 2022 at 09:12:37AM -0600 schrieb Dale:

> > On Sat, Dec 17, 2022 at 4:42 PM Dale <rdalek1967@gmail.com
> > <mailto:rdalek1967@gmail.com>> wrote:
> > <SNIP>
> > >
> > > My reasoning is simple, I'm already familiar with LVM and how to
> > manage it.  
> > <SNIP>
> > […]
> > Wipe the machine. You'll be happier.
> >
> > Best wishes,
> > Mark
>
> Well, I finally got it so I could do a backup.  I didn't need a hammer
> but the thought crossed my mind.  lol  Even tho I now have a 1GB network
> card, it's still really slow.  It shows up as a 1GB connection on both
> my Gentoo machine and the NAS machine.  This is a example of the speeds
> I'm seeing.  Just snippets. 
> 
> 
> 277,193,507 100%   16.18MB/s    0:00:16
> 519,216,571 100%   18.86MB/s    0:00:26
> 738,078,565 100%   23.54MB/s    0:00:29
> 
> 
> As you can see, the files sizes are large enough it should do better. 

Gbit nets at around 116..117 MB/s.

> When I use iftop, it shows it isn't doing anywhere near the speed it
> should, maybe 1/4th or so.  I'd expect at least double or triple that
> speed.  In all honesty, I'd think the hard drive would be the limiting
> factor.  Even on my Gentoo rig I only get about 50 to 60MBs/sec for
> encrypted drives.  I think the encryption slows that down.  When copying
> from a plain drive to a plain drive, I get 100MBs/sec or so. 
>
> I can't figure out why it is so slow tho.  The NAS rig is a 4 core CPU
> and 8GBs of memory.

OK, so you already noticed that encryption slows you down. This won’t happen
with a CPU that has AES instructions (well, and if the encryption you chose
actually uses AES, and not something else like Blowfish). So I guess your
CPU is too old, given your earlier descriptions.

When I built my NAS in November 2016, I installed a Celeron G1840 at first.
A very affordable (33 €) and frugal CPU (2 cores, 53 W, which were never
actually drawn). I knew it didn’t have AES back then (Intel removed that
limit from Celerons in architectures after Haswell), but from experiments I
knew it would achieve around 150..160 MB/s with LUKS, which was enough for
Gbit ethernet. But not for scrubs, when all HDDs were worked in parallel. So
after a year I did an upgrade after all and bought the smallest and cheapest
CPU that had AES, an i3-41xx.

> It should have enough horsepower under the hood. 
> Maybe it is something I'm not aware of.  It is a older rig so maybe it
> isn't SATA's fastest version, maybe even the original or something.  I

SATA 2 is 3 Gbit/s, so still not saturated by a single HDD.

Network transfers are single-core work. If it is really such an old machine,
I guess the CPU is the bottleneck again. Do you transfer via ssh? If so, use
something else that doesn’t encrypt the transport stream. When I am bound by
CPU in such cases (like with my ancient netbook with an Atom N450), and I
don’t want to set up a file server (that is nowhere near as flexible as ssh
anyways), I use netcat:

On the receiving end, start a netcat listener and extract from it:
nc -l -p $Portnumber | tar xf -
The portnumber must be any number above 1024, if you’re not root.

And on the sender, pack all your stuff into a tar (uncompressed!, since
videos aren’t compressible further and it will bog down the CPU again) and
pipe it to the receiver:
tar cf - * | nc $Destination_IP $Portnumber

Once the client is done, press Ctrl+C on the receiver.

Or maybe use rsync with the rsync-protocol instead of ssh. That’ll be more
flexible, because the tar-and-nc method doesn’t know about existing files on
the receiving end. (But I’ve never tested that approach.)

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

You sould borrow money only from pessimists, because they don’t expect it back.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]