Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Jun 2011 11:11:40 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Gleb Kurtsou <gleb.kurtsou@gmail.com>
Cc:        freebsd-fs@freebsd.org, Garance A Drosehn <gad@freebsd.org>
Subject:   Re: [rfc] 64-bit inode numbers
Message-ID:  <20110623081140.GQ48734@deviant.kiev.zoral.com.ua>
In-Reply-To: <20110623064333.GA2823@tops>
References:  <20101201091203.GA3933@tops> <20110104175558.GR3140@deviant.kiev.zoral.com.ua> <20110120124108.GA32866@tops.skynet.lt> <4E027897.8080700@FreeBSD.org> <20110623064333.GA2823@tops>

next in thread | previous in thread | raw e-mail | index | archive | help

--5ggoG3uILOsAbQb2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 23, 2011 at 09:43:33AM +0300, Gleb Kurtsou wrote:
> On (22/06/2011 19:19), Garance A Drosehn wrote:
> > On 1/20/11 7:41 AM, Gleb Kurtsou wrote:
> > > I've updated the patch. New version is available here:
> > > https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64-patch-20=
11-01-20.tgz
> > >
> > > Changelog:
> > > * Add fts, ftw, nftw compat shims in libc
> > > * Place libc compat shims in separate files, don't hack original
> > >    implementations.
> > > * Fix dump/restore
> > > * Use ino_t in UFS code (suggested by Kirk McKusick)
> > > * Keep ufs_ino_t (32 bit) for boot2 not to increase size
> > >   =20
> > Sorry for replying to an older message, but a reply made in a different
> > thread reminded me about this project...
> >=20
> > Also, I may have asked this before.  In fact, I'm almost sure that I st=
arted
> > a reply to this back in Jan/Feb, but my email client claims I never rep=
lied
> > to this topic...
> >=20
> > Are you increasing only the size of ino_t, or could you also look at
> > increasing the size of dev_t?   (just curious...)
>=20
> Sure. Incorporating as much of similar changes as possible is good.
> I've added Kostik and Matthew to CC list, it's for them to decide.
>=20
> dev_t on other OSes:
> 	NetBSD - uint64_t
> 	DragonFly - uint32_t
> 	Darwin - __int32_t=20
> 	OpenSolaris - ulong_t
> 	Linux - __u32
>=20
> Considering this I think 3rd party software is not ready for such
> change.
>=20
> Major/minor mapping to dev_t will get more complicated.
>=20
> And the most important question: what would you want it for? As far as I
Indeed, this is the right question.

> can see major/minor numbers are ignored nowadays, major is zero, minor
> increases independently of device type:
This is only because you have too little /dev nodes.
Look at the definitions of the major/minor in sys/types.h.

--5ggoG3uILOsAbQb2
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iEYEARECAAYFAk4C9TsACgkQC3+MBN1Mb4hOUACeJkrSB7qRjgbCOx3ky68kn+Be
xg8Anj0HolhhVzm0KYtLOiroNlVeodqg
=82h2
-----END PGP SIGNATURE-----

--5ggoG3uILOsAbQb2--



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