From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 16:20:45 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E11B16A41F for ; Thu, 1 Sep 2005 16:20:45 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3281B43D45 for ; Thu, 1 Sep 2005 16:20:43 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id j81GKXsK080104; Thu, 1 Sep 2005 19:20:33 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Thu, 1 Sep 2005 19:20:33 +0300 (EEST) From: Dmitry Pryanishnikov To: Bruce Evans Message-ID: <20050901183311.D62325@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 16:20:45 -0000 Hello! > Date: Thu, 1 Sep 2005 23:47:15 +1000 (EST) > From: Bruce Evans >> 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@atlantis.dp.ua nic-hdl: LYNX-RIPE