From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 22:27:23 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7561D37B401 for ; Wed, 16 Jul 2003 22:27:23 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id E08A043F75 for ; Wed, 16 Jul 2003 22:27:22 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-uinj8ql.dialup.mindspring.com ([165.121.163.85] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19d1IV-00076S-00; Wed, 16 Jul 2003 22:27:20 -0700 Message-ID: <3F16337B.3004C77E@mindspring.com> Date: Wed, 16 Jul 2003 22:26:19 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?S=B3awek=20=AFak?= References: <867k6iagj4.fsf@thirst.corponet.era.pl> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ab41047d2dc1d280c16e9ec372199be7387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: freebsd-current@freebsd.org Subject: Re: NFS problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2003 05:27:23 -0000 S=B3awek =AFak wrote: > I guess there is something wrong with exporting iso9660 CD's over NFS. = I've added > = > /cdrom -ro -mapall=3Droot > = > to /etc/exports, restarted mountd and after mounting the CD on Solaris = 8. All the > files are 0-sized, dates are set back to the epoch and directories are = seen as > files. Exporting ufs2 filesystems works as expected. [ ... ] > Any thoughts? Yes. Exporting FS's is not as simple as simply doing it. The API in FreeBSD needs changed somewhat to support this at a higher layer. Even so, the hacked ISO9660 code is actually OK for the volume export. The problem comes in that the consumer of the FS is assumed to have the ability to translate certain attributes when the struct direct and stat structures are externalized to the NFS server code, which is a VFS client. You are certain you don't see these same attributes on /cdrom itself, form a shell when you cd to /cdrom? If your answer is "no", then it's definitely the externalization of the stat structure and things like struct direct. Note that the NFS over-the-wire stat structure is *not* the same as the FFS version which it exports to the stat(2) and fstat(2) system calls. Probably the thing to do is to look at the differences in the code, and not assume that the VFS client is always the system call layer. -- Terry