kern/85503: panic: wrong dirclust using msdosfs in RELENG_6

[Bruce Evans]

On Sat, 3 Sep 2005, Dmitry Pryanishnikov wrote:

> On Fri, 2 Sep 2005, Bruce Evans wrote:
>> Actually u_int is 32 bits for ia64, and the ino_t API/ABI is indenpendent
>> of the size of u_int.  ino_t is uint32_t.
>
> Hmm, what about other 64-bit architectures (e.g. alpha)? I used to think 
> that on 64-bit CPUs type int should have 64 bits.

They all use 32-bit for binary and (badly written) source compatiblity.
I tend to agree that ints should be 64 bits on true 64 bit machines,
since longs should be twice as large as the register size and that leaves
nothing except ints among the standard integer types for actually using
plain 64-bit registers.

>> offsets within files.  Sicne off_t is unsigned, it is unsuitable for
> -------------------------------^^^^^^^^^^^^^^^^^
>
> No, it's signed ;)

Oops.

>> representing offsets within file systems.  It just happens to work
>> because it is 64 bits and an offset of 2^63-1 bytes is enough for
>> anyone ;-).  (Actually it is not even enough for offsets within files
>> since offsets in /dev/kmem are often > 2^63 on 64-bit systems.) ino_t
>
> I think that any file system should be flexible enough to support maximum
> file size as large as file system size (ideally). So if off_t is suitable
> for representing offset within single file, it should also be suitable
> for representing offset within filesystem, because their maximum sizes
> are almost the same. Also, I don't understand why signedness of the type
> makes any difference: whe're working with offsets from the start of
> our media, so all offsets are positive.

off_t is also needed to represent negative offsets for SEEK_EOF.  Thus it
must be a signed type, and its range must be from -(signed)(maxfilesize+1)
to maxfilesize+1.  2's complement types can't do that right without
retricting the max file size to about half of the range of the corresponding
unsigned type.  So 64-bit registers/off_t's give a max file size limit of
2^63-2, not 2^64-1 (-2 so that 1 can be added to maxfileize -- the offset
is maxfilesize+1 at EOF for a file with max size), and 64-bit address spaces
cannot be addressed by 64-bit off_t's without kludges; even a 65-bit off_t
is 1 or 2 values short since 1 more value is needed for 2^64 and another
for an out-of-band error return value.

> I'm trying to be as general as possible. Size of direct access media (disks)
> tends to increase, so (in order not to rewrite disk layers every 5 years)
> we should have a basic data type which is suitable to hold media size
> in bytes. In fact I think that we already have this type (off_t). Also,
> it's clear that no media can contain more files than it's size in bytes,
> so this data type should also represent file number (inode number, if
> this sounds better ;).

The latter is not clear :-).  Lots of compression is possible.

>> is closer to being the correct type.  The type of v_hash certainly needs
>> to be larger than ino_t.  My main point is that although it could be
>> larger so that file systems can easily create a (unique) id from things
>> like (dirclust, diroffset) pairs, it is not useful for it to be larger
>> since file systems need to create an id for the inode number anyway.
>> (Creation in some file system, e.g. ffs, is just copying the inode
>> number from the inode.)
>
> Of course, size of ino_t should also be upgraded. But I understand that
> it isn't an easy task.

phk pointed out the simple method (already needed and used for nfs)
for fixing vnode lookup.  This leaves the problem of fixing inode numbers
for userland.  cd9660 has much the same problems as msdosfs.  udf seems
to get a fileid off the media.  I wonder if fileids off media can be
trusted for vnode lookup.

Bruce