From: Helge Deller <deller@gmx.de>
To: Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] Time-based RFC 4122 UUID generator
Date: Sun, 18 Nov 2007 22:40:34 +0100
User-Agent: KMail/1.9.7
Cc: linux-kernel@vger.kernel.org, Theodore Tso <tytso@mit.edu>
References: <200711182038.22055.deller@gmx.de> <20071118130503.7d5ec842.akpm@linux-foundation.org>
In-Reply-To: <20071118130503.7d5ec842.akpm@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200711182240.35015.deller@gmx.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3454
Lines: 69

On Sunday 18 November 2007, Andrew Morton wrote:
> On Sun, 18 Nov 2007 20:38:21 +0100 Helge Deller <deller@gmx.de> wrote:
> 
> > Title: Add time-based RFC 4122 UUID generator
> > 
> > The current Linux kernel currently contains the generate_random_uuid() 
> > function, which creates - based on RFC 4122 - truly random UUIDs and 
> > provides them to userspace through /proc/sys/kernel/random/boot_id and 
> > /proc/sys/kernel/random/uuid.
> > 
> > This patch additionally adds the "Time-based UUID" variant of RFC 4122, 
> > with which userspace applications can easily get real unique time-based 
> > UUIDs through /proc/sys/kernel/random/uuid_time.
> > A new /proc/sys/kernel/random/uuid_time_clockseq sysfs entry is available,
> > so that the clock_seq value can be retained across system bootups (which
> > is required by RFC 4122).
> > 
> > The attached implementation uses getnstimeofday() to get very fine-grained
> > granularity. This helps, so that userspace tools can get a lot more UUIDs 
> > (if needed) per time than before.
> > A mutex takes care of the proper locking against a mistaken double creation 
> > of UUIDs for simultanious running processes.


> Who will use this feature, and for what?
> (In fact, who uses the existing UUID generators, and for what?)

Current users I know of (but there are more):
- e2fsprogs uses it e.g. to create unique UUIDs for disks (it ships an own library for that)
- http://commons.apache.org/sandbox/id/uuid.html uses it with own libraries
- SAP Netweaver on Linux uses it (http://www.sap.com/platform/netweaver/index.epx)

I'm mostly interested in fixing problems I see with SAP (I'm working for SAP).
SAP Netweaver often needs during a very short time frame lots of unique UUIDs 
(to reference the data afterwards) when new data is imported into the database.
Main problem with current implementations is, is that they don't 100% 
guarantee uniqness of the generated UUIDs. Sometimes, esp. on very fast 
multi-processor machines, double UUIDs are generated and returned to the 
application which is very bad and may result in unreliable behaviour.

Current implemenations use userspace-libraries. In userspace you e.g. can't 
easily protect the uniquness of a UUID against other running _processes_.
If you try do, you'll need to do locking e.g. with shared memory, which can 
get very expensive.
My in-kernel implementation does guarantee the uniquness through the mutex.

The problem will get even worse with virtualization technologies like XEN and
containers. There it's even impossible to protect against processes in other VMs.

Another user which could benefit from it are embedded devices. They could 
drop their userspace-implementations in favour of this smaller kernel version
to create UUIDs for their disks, using it in the webservers, ...

Best regards,
Helge


PS:
I did created bugreports against the e2fsprogs userspace implementation 
at Red Hat and Novell (only accessible for RH/Novell employees), but as I 
explained above, the userspace-implementation may not be sufficient:
https://bugzilla.redhat.com/show_bug.cgi?id=233471 
https://bugzilla.redhat.com/show_bug.cgi?id=218606 
https://bugzilla.novell.com/show_bug.cgi?id=189640
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/