On Sunday 18 November 2007, Andrew Morton wrote:
> On Sun, 18 Nov 2007 20:38:21 +0100 Helge Deller <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
