[Dorset] Curious anecdote about using ecryptfs

2022-02-09 Thread Hamish McIntyre-Bhatty

Hi there,

Somewhat related to my question about TRIM, I recently thought my SSDs 
were performing badly (for NVMe drives) when transferring files between 
them - it seems to be very SATA-ish speeds of around 500-600MB/s when 
transferring files between drives (one for my home partition, the other 
for the ridiculous number of VMs I need).


It turns out this was not due to TRIM, but due to eCryptFS:

When dd'ing with an 8 MB block size, both disks can write at about 
1.6GB/s - as expected.


When dd'ing to the eCryptFS part of my /home partition, I get write 
speeds of about 600MB/s and read speeds of 1.2GB/s. I get speeds of 
800MB/s when transferring from the eCrpytFS'd part of /home to my VMs 
drive, but if 1.8GB/s from the unencrypted portion.


TL;DR: on my CPU (Ryzen 3600 at stock clock speeds) the eCryptFS 
encryption speeds just so happen to limit drives to SATA-ish speeds for 
both transfers in and out of the encrypted area. I suspect the transfer 
out of the eCryptFS storage being slower than just dumping to /dev/null 
is due to the IO being very single-threaded in the kernel?


At any rate, the encryption/decryption is definitely single-threaded.

Thank you for coming to my TED talk that you neither volunteered to 
attend, and (probably) nor were especially interested to read :)


Hamish


--
 Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
 Check to whom you are replying
 Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
 New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


Re: [Dorset] fstrim weirdness

2022-02-09 Thread Hamish McIntyre-Bhatty

On 09/02/2022 18:23, Neil Stone wrote:

See also 'anacron' to run cron tasks that were missed due to the system
being off.

Hi Victor, many years since we spoke last o/

On Wed, 9 Feb 2022 at 18:16, Victor Churchill 
wrote:


I've not used fstrim, but I assume you're putting a fstrim command into
your crontab but concerned that it won't run if the machine is shut down
before the cron time comes round.
Have you seen the cron '@reboot' facility? This will run whatever command
you give it when Linux starts.
You might want to give it a script which checks for the existence of some
flag to tell it whether it wqants to run fstrim or not, depending on
whether fstrim got run by a regular scheduled cronjob (which could set
aforesaid flag).

best regards,
웃
Victor Churchill,
Netley Abbey, Southampton



On Wed, 9 Feb 2022 at 17:57, Hamish McIntyre-Bhatty 
wrote:


Hi there,

I believe a while back I was talking about TRIM here, more specifically
about it not running automatically on my systems, and I think someone
recommended I enable fstrim.service with systemd.

I finally got around to that, only to find that it was already enabled,
and apparently not doing anything. As I don't leave my systems on 24/7,
is it safe to assume that the timer isn't firing when the system is
booted up later, after the configured time for TRIM has passed?

If so, does anyone know how to configure a task like this to run when
scheduled, or alternatively when the system is next booted up in the
case that the event was missed?

I know CRON can't do this, and I assumed the point of using systemd
timers was that they could do this, but alas perhaps not. I assume there
must be a standard way to do this, because it seems like a rather big
omission, considering that other commercial operating systems Who Must
Not Be Named (TM) seem to have had this feature for a while.

Any ideas?

Hamish


--
   Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
   Check to whom you are replying
   Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
   New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


--
   Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
   Check to whom you are replying
   Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
   New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


Cheers all,

I have added:

7   50  fstrim  -av

To /etc/anacrontab. Hopefully that'll do it.

This should really be in there for most distributions by default IMO.

Hamish



--
 Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
 Check to whom you are replying
 Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
 New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


Re: [Dorset] fstrim weirdness

2022-02-09 Thread Neil Stone
See also 'anacron' to run cron tasks that were missed due to the system
being off.

Hi Victor, many years since we spoke last o/

On Wed, 9 Feb 2022 at 18:16, Victor Churchill 
wrote:

> I've not used fstrim, but I assume you're putting a fstrim command into
> your crontab but concerned that it won't run if the machine is shut down
> before the cron time comes round.
> Have you seen the cron '@reboot' facility? This will run whatever command
> you give it when Linux starts.
> You might want to give it a script which checks for the existence of some
> flag to tell it whether it wqants to run fstrim or not, depending on
> whether fstrim got run by a regular scheduled cronjob (which could set
> aforesaid flag).
>
> best regards,
> 웃
> Victor Churchill,
> Netley Abbey, Southampton
>
>
>
> On Wed, 9 Feb 2022 at 17:57, Hamish McIntyre-Bhatty 
> wrote:
>
> > Hi there,
> >
> > I believe a while back I was talking about TRIM here, more specifically
> > about it not running automatically on my systems, and I think someone
> > recommended I enable fstrim.service with systemd.
> >
> > I finally got around to that, only to find that it was already enabled,
> > and apparently not doing anything. As I don't leave my systems on 24/7,
> > is it safe to assume that the timer isn't firing when the system is
> > booted up later, after the configured time for TRIM has passed?
> >
> > If so, does anyone know how to configure a task like this to run when
> > scheduled, or alternatively when the system is next booted up in the
> > case that the event was missed?
> >
> > I know CRON can't do this, and I assumed the point of using systemd
> > timers was that they could do this, but alas perhaps not. I assume there
> > must be a standard way to do this, because it seems like a rather big
> > omission, considering that other commercial operating systems Who Must
> > Not Be Named (TM) seem to have had this feature for a while.
> >
> > Any ideas?
> >
> > Hamish
> >
> >
> > --
> >   Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
> >   Check to whom you are replying
> >   Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
> >   New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk
> >
> --
>   Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
>   Check to whom you are replying
>   Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
>   New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk
>
-- 
  Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
  Check to whom you are replying
  Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
  New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


Re: [Dorset] fstrim weirdness

2022-02-09 Thread Victor Churchill
I've not used fstrim, but I assume you're putting a fstrim command into
your crontab but concerned that it won't run if the machine is shut down
before the cron time comes round.
Have you seen the cron '@reboot' facility? This will run whatever command
you give it when Linux starts.
You might want to give it a script which checks for the existence of some
flag to tell it whether it wqants to run fstrim or not, depending on
whether fstrim got run by a regular scheduled cronjob (which could set
aforesaid flag).

best regards,
웃
Victor Churchill,
Netley Abbey, Southampton



On Wed, 9 Feb 2022 at 17:57, Hamish McIntyre-Bhatty 
wrote:

> Hi there,
>
> I believe a while back I was talking about TRIM here, more specifically
> about it not running automatically on my systems, and I think someone
> recommended I enable fstrim.service with systemd.
>
> I finally got around to that, only to find that it was already enabled,
> and apparently not doing anything. As I don't leave my systems on 24/7,
> is it safe to assume that the timer isn't firing when the system is
> booted up later, after the configured time for TRIM has passed?
>
> If so, does anyone know how to configure a task like this to run when
> scheduled, or alternatively when the system is next booted up in the
> case that the event was missed?
>
> I know CRON can't do this, and I assumed the point of using systemd
> timers was that they could do this, but alas perhaps not. I assume there
> must be a standard way to do this, because it seems like a rather big
> omission, considering that other commercial operating systems Who Must
> Not Be Named (TM) seem to have had this feature for a while.
>
> Any ideas?
>
> Hamish
>
>
> --
>   Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
>   Check to whom you are replying
>   Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
>   New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk
>
-- 
  Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
  Check to whom you are replying
  Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
  New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


Re: [Dorset] fstrim weirdness

2022-02-09 Thread Neil Stone
I run this from root cron...

00  4   *   *   *   /sbin/fstrim -av

you can, of course, change the timing to whatever you want.

HTH

On Wed, 9 Feb 2022 at 17:57, Hamish McIntyre-Bhatty 
wrote:

> Hi there,
>
> I believe a while back I was talking about TRIM here, more specifically
> about it not running automatically on my systems, and I think someone
> recommended I enable fstrim.service with systemd.
>
> I finally got around to that, only to find that it was already enabled,
> and apparently not doing anything. As I don't leave my systems on 24/7,
> is it safe to assume that the timer isn't firing when the system is
> booted up later, after the configured time for TRIM has passed?
>
> If so, does anyone know how to configure a task like this to run when
> scheduled, or alternatively when the system is next booted up in the
> case that the event was missed?
>
> I know CRON can't do this, and I assumed the point of using systemd
> timers was that they could do this, but alas perhaps not. I assume there
> must be a standard way to do this, because it seems like a rather big
> omission, considering that other commercial operating systems Who Must
> Not Be Named (TM) seem to have had this feature for a while.
>
> Any ideas?
>
> Hamish
>
>
> --
>   Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
>   Check to whom you are replying
>   Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
>   New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk
>
-- 
  Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
  Check to whom you are replying
  Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
  New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


[Dorset] fstrim weirdness

2022-02-09 Thread Hamish McIntyre-Bhatty

Hi there,

I believe a while back I was talking about TRIM here, more specifically 
about it not running automatically on my systems, and I think someone 
recommended I enable fstrim.service with systemd.


I finally got around to that, only to find that it was already enabled, 
and apparently not doing anything. As I don't leave my systems on 24/7, 
is it safe to assume that the timer isn't firing when the system is 
booted up later, after the configured time for TRIM has passed?


If so, does anyone know how to configure a task like this to run when 
scheduled, or alternatively when the system is next booted up in the 
case that the event was missed?


I know CRON can't do this, and I assumed the point of using systemd 
timers was that they could do this, but alas perhaps not. I assume there 
must be a standard way to do this, because it seems like a rather big 
omission, considering that other commercial operating systems Who Must 
Not Be Named (TM) seem to have had this feature for a while.


Any ideas?

Hamish


--
 Next meeting: Online, Jitsi, Tuesday, 2022-03-01 20:00
 Check to whom you are replying
 Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk
 New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk