Messages in this thread | | | Date | Tue, 20 Nov 2007 00:31:20 -0600 | From | Matt Mackall <> | Subject | Re: [PATCH] Time-based RFC 4122 UUID generator |
| |
On Sun, Nov 18, 2007 at 10:40:34PM +0100, Helge Deller wrote: > 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.
Even with a futex? Or userspace atomics? I think something as simple as a server stuffing a bunch of clock sequence numbers into a pipe for clients to pop into their generated UUIDs should be plenty fast enough.
> 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.
Nor does it make sense to try! A virtual machine is an independent machine after all.
> 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, ...
That's a silly tradeoff. It's an unusual embedded device that ships with any need for a UUID, especially mkfs. And generally, putting a feature in the kernel has no inherent size advantage. In fact, it has a size disadvantage: it's no longer pageable.
ps: I'm the listed random.c maintainer so you'll want to cc: me in the future. -- Mathematics is the supreme nostalgia of our time. - 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/
| |