Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Mar 2002 16:56:20 -0500
From:      Garance A Drosihn <drosih@rpi.edu>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Poul-Henning Kamp <phk@critter.freebsd.dk>, Harti Brandt <brandt@fokus.gmd.de>, Robert Watson <rwatson@FreeBSD.ORG>, Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG
Subject:   Re: Increasing the size of dev_t and ino_t
Message-ID:  <p05101558b8b426ace9ca@[128.113.24.47]>
In-Reply-To: <3C8E6AC0.A51444E1@mindspring.com>
References:  <60373.1015917340@critter.freebsd.dk> <p05101551b8b3c1f14df9@[128.113.24.47]> <3C8E6AC0.A51444E1@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
At 12:53 PM -0800 3/12/02, Terry Lambert wrote:
>Garance A Drosihn wrote:
>>  Now for suggestion part #2:
>>
>>  Once we get to a 64-bit (u)dev_t, we could reserve one byte of
>>  that for the "type of filesystem" (loosely speaking).  A value
>  > of   0 for local hard disks
>  >      3 for OpenAFS or ARLA mounted
>  >      4 for CODA-mounted              [...etc...]
>
>man statfs.
>
>The answer is that it's possible to get the FS mount type
>already.

This would not be to get the fs mount type, it would be to avoid
duplicate values for st_dev.  By using one byte to explicitly
indicate the "pool of numbers" one is picking values for, each
"pool" can pick whatever values it wants for the remaining bits.

Thus we could use the creation-date of a hard-disk filesystem
for dev_t in the case of hard disks (if we wanted to), and not
have to worry that it might be the same as some id in AFS-land.

This is an implementation detail of how to ensure a unique value
for st_dev, when we're talking about billions of such values (in
the case of AFS or Coda).  This is not something we would document
for use in any userland-level code.

-- 
Garance Alistair Drosehn            =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101558b8b426ace9ca>