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

[Dmitry Pryanishnikov]

Hello!

> Date:      Thu, 1 Sep 2005 23:47:15 +1000 (EST)
> From:      Bruce Evans <bde at zeta.org.au>
>>        LIST_ENTRY(vnode)       v_hashlist;
>>        u_int                   v_hash;
>>
>> I think it's feasible and useful to upgrade type of v_hash to at least 
>> off_t.
>
> This is not needed yet.
>
> Filesystems with more than 4G files are not supported yet, since ino_t
> is 32 bits and is used in critical APIs (struct stat...).  Also,

  Sorry, I don't agree with you. The current situation is ugly: not only
it forces us to play dirty tricks within filesystems in order to generate
unique 32-bit inode numbers, but also it creates an artificial limit
on maximum number of files for 32-bit architectures. E.g., on FreeBSD/ia64
u_int is 64 bits, and thus it would be no problem for it's API to create and 
handle more than 4G files/fs. But such a file system will be incompatible 
with FreeBSD/i386! Isn't this ugly? u_int has nothing to do with storage
size, while off_t has. It is clear that no media with maximum size of
off_t will contain more than off_t files, while we can't guarantee this
for u_int, which is bounded to CPU abilities. I think UNIX is about
compatibility between different architectures, isn't it?

> So all current file systems need to generate unique 32-bit inode
> numbers.  This may be difficult, but once it is done I think the inode
                  ^^^^^^^^^^^^^^^^

   ...and may be close-to-impossible. What if e.g. Microsoft invites say 
FAT-2005 with variable-length directory entries? I'm not sure that for
every third-party filesystem it would be possible to generate 32-bit
pseudoinode. And it's very bad that we can't handle >4Gfiles/fs at all.

> For msdosfs, the inode number is essentially the byte offset divided by
> the size of a directory entry.  The size is 32, so this breaks at a byte
> offset of 128G instead of 4G.  Details:

  This is also imperfect: it creates a lot of pain and limitations for

options         MSDOSFS_LARGE

So, while I understand complexity of such a transitions, but it's clear
that for long-term solution ino_t should be upgraded to the size of off_t 
everywhere. For short-term one... Well, msdosfs isn't the worst case.

>
> Bruce
>

Sincerely, Dmitry
-- 
Atlantis ISP, System Administrator
e-mail:  dmitry at atlantis.dp.ua
nic-hdl: LYNX-RIPE