DragonFly kernel List (threaded) for 2007-02
DragonFly BSD
DragonFly kernel List (threaded) for 2007-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Initial filesystem design synopsis.


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 22 Feb 2007 10:24:58 -0800 (PST)

:Hi,
:
:At 22:22 21/02/2007, Matthew Dillon wrote:
:>[...]
:>     Plus, I need a name for this baby. I can't use DFS, however much I
:>     want to, because the term is already over-used.
:
:If you went for 128-bit object IDs you could call it UFSv6 :-) :-)
:
:But seriously, instances of this filesystem will potentially be very 
:big, very active *and* have very long lifetimes - is 64 bits really enough?
:
:--
:Bob Bishop		    +44 (0)118 940 1243
:rb@gid.co.uk		fax +44 (0)118 940 1295

    What would be a reasonable limit of the number of replication targets
    operating in master mode (master == changes can be made, slave == changes
    can only be brought in through replication protocols).

    Lets choose 64.  Now, what would be a reasonable limit for the number of
    discrete MODIFYING operations per second?  Lets choose 10000000
    (ten million).

    So, that's 6 bits to identify replication master, and 24 bits for 
    sub-second resolution, leaving 40 bits for one-second resolution. 

    40 bits of one-second resolution comes to around 34865 years.

    And its even better then that.  For this filesystem, transaction ids 
    are created by synchronization events for modified data, not modifying
    events.  Such events occur far less often then the actual modifying
    operations execuuted by programs.

    64 bits is enough.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]