[PATCH] libuuid: Move clock.txt to /run

[PATCH] libuuid: Move clock.txt to /run

[Michal Suchanek]

Some users complain that due to filesystem performance of writing the
clock.txt generating UUIDs is slow.

uuidd would solve this but some distributions do not run it by default.

Moving the clock.txt to /run which is in tmpfs should resolve the
problem even for users not running uuidd.

Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
 libuuid/src/uuidP.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libuuid/src/uuidP.h b/libuuid/src/uuidP.h
index 200702c1e..574a30fca 100644
--- a/libuuid/src/uuidP.h
+++ b/libuuid/src/uuidP.h
@@ -39,7 +39,7 @@
 
 #include "uuid.h"
 
-#define LIBUUID_CLOCK_FILE	"/var/lib/libuuid/clock.txt"
+#define LIBUUID_CLOCK_FILE	"/run/libuuid/clock.txt"
 
 /*
  * Offset between 15-Oct-1582 and 1-Jan-70
-- 
2.39.2

Re: [PATCH] libuuid: Move clock.txt to /run

[Chris Hofstaedtler]

* Michal Suchanek <msuchanek@suse.de> [230301 15:10]:
> Moving the clock.txt to /run which is in tmpfs should resolve the
> problem even for users not running uuidd.
[..]
>  
> -#define LIBUUID_CLOCK_FILE	"/var/lib/libuuid/clock.txt"
> +#define LIBUUID_CLOCK_FILE	"/run/libuuid/clock.txt"

Last time I asked about this file on this mailing list, I was
informed that clock.txt is supposed to survive reboots.
Moving it to /run (or any other tmpfs) would break this.

Chris

Re: [PATCH] libuuid: Move clock.txt to /run

[Michal Suchánek]

On Wed, Mar 01, 2023 at 03:17:47PM +0100, Chris Hofstaedtler wrote:
> * Michal Suchanek <msuchanek@suse.de> [230301 15:10]:
> > Moving the clock.txt to /run which is in tmpfs should resolve the
> > problem even for users not running uuidd.
> [..]
> >  
> > -#define LIBUUID_CLOCK_FILE	"/var/lib/libuuid/clock.txt"
> > +#define LIBUUID_CLOCK_FILE	"/run/libuuid/clock.txt"
> 
> Last time I asked about this file on this mailing list, I was
> informed that clock.txt is supposed to survive reboots.
> Moving it to /run (or any other tmpfs) would break this.

What's so valuable in it that it needs to survive?

I don't have it at all.

Also the code seems to re-synchronize with the real time clock from time
to time which makes the content relevant only for limited periods of
time.

Thanks

Michal

Re: [PATCH] libuuid: Move clock.txt to /run

[Theodore Ts'o]

On Wed, Mar 01, 2023 at 03:26:04PM +0100, Michal Suchánek wrote:
> > Last time I asked about this file on this mailing list, I was
> > informed that clock.txt is supposed to survive reboots.
> > Moving it to /run (or any other tmpfs) would break this.
> 
> What's so valuable in it that it needs to survive?
> 
> I don't have it at all.
> 
> Also the code seems to re-synchronize with the real time clock from time
> to time which makes the content relevant only for limited periods of
> time.

The concern is if the system time goes backwards, this could result in
a duplicative UUID being returned.  This was especially a concern for
systems that were dual-booting with Windows, where Windows set the
real-time clock to localtime, and Linux set the real-time clock to
GMT, and so the real time clock on those systems had a tendency to
bound around a *lot*.

Using a random number generator for clock can help, but it's only 13
bits, so it's certainly not fool-proof.  Given that using a time-based
UUID leaks the MAC address of your ethernet port as well as when the
UUID was generated (which can be interesting when you're curious say,
when a Libreoffice doc was created), in general best practice is to
use the random UUID type, especially given that modern Linux systems
all have the getrandom(2) system call.  That gives you 58 bits of
entropy in the UUID, so that's probably the better way to go.

Cheers,

					- Ted

Re: [PATCH] libuuid: Move clock.txt to /run

[Michal Suchánek]

On Wed, Mar 01, 2023 at 11:49:57AM -0500, Theodore Ts'o wrote:
> On Wed, Mar 01, 2023 at 03:26:04PM +0100, Michal Suchánek wrote:
> > > Last time I asked about this file on this mailing list, I was
> > > informed that clock.txt is supposed to survive reboots.
> > > Moving it to /run (or any other tmpfs) would break this.
> > 
> > What's so valuable in it that it needs to survive?
> > 
> > I don't have it at all.
> > 
> > Also the code seems to re-synchronize with the real time clock from time
> > to time which makes the content relevant only for limited periods of
> > time.
> 
> The concern is if the system time goes backwards, this could result in
> a duplicative UUID being returned.  This was especially a concern for
> systems that were dual-booting with Windows, where Windows set the
> real-time clock to localtime, and Linux set the real-time clock to
> GMT, and so the real time clock on those systems had a tendency to
> bound around a *lot*.
> 
> Using a random number generator for clock can help, but it's only 13
> bits, so it's certainly not fool-proof.  Given that using a time-based
> UUID leaks the MAC address of your ethernet port as well as when the
> UUID was generated (which can be interesting when you're curious say,
> when a Libreoffice doc was created), in general best practice is to
> use the random UUID type, especially given that modern Linux systems
> all have the getrandom(2) system call.  That gives you 58 bits of
> entropy in the UUID, so that's probably the better way to go.

That explains why I don't have a clock.txt file. I did not go out of my
way to generate time-based uuids.

Thanks

Michal

Re: [PATCH] libuuid: Move clock.txt to /run

[Karel Zak]

On Wed, Mar 01, 2023 at 03:09:57PM +0100, Michal Suchanek wrote:
> Some users complain that due to filesystem performance of writing the
> clock.txt generating UUIDs is slow.

XFS right? ;-)

> uuidd would solve this but some distributions do not run it by default.

For some performance critical use-cases you will see this issue with
uuidd too. The latest changes in the libuuid and uuidd solves this
problem by continuous-clock where uuidd uses dedicated clock sequence
range to avoid often state-file updates. 

Numbers from Michael (author of the patch)

 The classic setup delivered <430.000 uuid/sec on average.
 The cont-clock setup delivered >6.800.000 uuid/sec on average.

I hope we will have -rc1 with this change this week.

Note that generate large number of time-based UUIDs without uuidd does
not make sense.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH] libuuid: Move clock.txt to /run

[Theodore Ts'o]

On Wed, Mar 01, 2023 at 06:17:59PM +0100, Michal Suchánek wrote:
> > Using a random number generator for clock can help, but it's only 13
> > bits, so it's certainly not fool-proof.  Given that using a time-based
> > UUID leaks the MAC address of your ethernet port as well as when the
> > UUID was generated (which can be interesting when you're curious say,
> > when a Libreoffice doc was created), in general best practice is to
> > use the random UUID type, especially given that modern Linux systems
> > all have the getrandom(2) system call.  That gives you 58 bits of
> > entropy in the UUID, so that's probably the better way to go.
> 
> That explains why I don't have a clock.txt file. I did not go out of my
> way to generate time-based uuids.

Note that the only reason why you might be trying to generate a huge
number of time-based UUID is if you are running a database (cough,
SAP, cough) that is doing database index compression hacks so they can
use still (a) use UUID's, but (b) not pay the cost of 16-byte UUID for
every single object in their database.

But if they are doing this, you ***really*** want to be using uuidd,
because even using clock.txt in tmpfs, it's going to be *way* faster
to use uuidd, and since some workloads (cough, SAP, cough) are
creating a vast number of UUID's per second while initializing their
database, your distribution users *will* want to install uuidd if they
are using those kinds of Enterprise Resource Planning systems.  If you
consider how much per hour these users pay for their certified
implementation consultsants, it's worth real $$$.   :-)

	       		     	  	     - Ted

Re: [PATCH] libuuid: Move clock.txt to /run

[Michal Suchánek]

On Wed, Mar 01, 2023 at 01:39:52PM -0500, Theodore Ts'o wrote:
> On Wed, Mar 01, 2023 at 06:17:59PM +0100, Michal Suchánek wrote:
> > > Using a random number generator for clock can help, but it's only 13
> > > bits, so it's certainly not fool-proof.  Given that using a time-based
> > > UUID leaks the MAC address of your ethernet port as well as when the
> > > UUID was generated (which can be interesting when you're curious say,
> > > when a Libreoffice doc was created), in general best practice is to
> > > use the random UUID type, especially given that modern Linux systems
> > > all have the getrandom(2) system call.  That gives you 58 bits of
> > > entropy in the UUID, so that's probably the better way to go.
> > 
> > That explains why I don't have a clock.txt file. I did not go out of my
> > way to generate time-based uuids.
> 
> Note that the only reason why you might be trying to generate a huge
> number of time-based UUID is if you are running a database (cough,

Thanks for the very detailed explanation.

I suppose the default is fine for most users then, and makes it
reasonably safe to use time basedd uuids for users of systems like
Raspberry Pi which exhibit weird time jumps, likely due to lack of RTC
battery.

uuidd is provided for people who want to generate large quantities of
UUIDs.

When somebody *really* wants and it improves their use case they can
mount tmpfs on /var/lib/libuuid/

Might be nice to write down in the uuid_generate man page if this is
coming up repeatedly.

Thanks

Michal