From owner-freebsd-fs Thu Aug 28 16:49:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27448 for fs-outgoing; Thu, 28 Aug 1997 16:49:17 -0700 (PDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.235]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA27434 for ; Thu, 28 Aug 1997 16:49:11 -0700 (PDT) Received: from k2.cup.hp.com (k2.cup.hp.com [15.0.97.218]) by palrel1.hp.com (8.8.6/8.8.5) with ESMTP id QAA16867 for ; Thu, 28 Aug 1997 16:49:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by k2.cup.hp.com with SMTP (8.7.1/8.7.3 TIS Messaging 5.0) id QAA04510 for ; Thu, 28 Aug 1997 16:49:02 -0700 (PDT) Message-Id: <199708282349.QAA04510@k2.cup.hp.com> X-Authentication-Warning: k2.cup.hp.com: Host localhost [127.0.0.1] didn't use HELO protocol Reply-To: jmattson@wco.com To: freebsd-fs@freebsd.org Subject: MS-DOS file system issues Date: Thu, 28 Aug 1997 16:49:01 -0700 From: Jim Mattson Sender: owner-freebsd-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I see that fixing the MS-DOS file system is a high priority task, but just exactly how broken is it? I mount most of my logical DOS drives ro out of paranoia, but I've got one small throw-away partition mounted rw for pushing things over to the Win95 world. I keep waiting for it to eat my data, and it hasn't happened yet. I would like to see Win95 long filename support, and I'd be willing to work on that, but are there more fundamental flaws that I'm missing? Thanks, --jim From owner-freebsd-fs Thu Aug 28 18:53:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04280 for fs-outgoing; Thu, 28 Aug 1997 18:53:15 -0700 (PDT) Received: from eac.iafrica.com (196-31-98-51.iafrica.com [196.31.98.51]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04271 for ; Thu, 28 Aug 1997 18:53:02 -0700 (PDT) Received: (from rnordier@localhost) by eac.iafrica.com (8.8.5/8.6.12) id DAA09891; Fri, 29 Aug 1997 03:44:58 +0200 (SAT) From: Robert Nordier Message-Id: <199708290144.DAA09891@eac.iafrica.com> Subject: Re: MS-DOS file system issues In-Reply-To: <199708282349.QAA04510@k2.cup.hp.com> from Jim Mattson at "Aug 28, 97 04:49:01 pm" To: jmattson@wco.com Date: Fri, 29 Aug 1997 03:44:57 +0200 (SAT) Cc: freebsd-fs@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jim Mattson wrote: > I see that fixing the MS-DOS file system is a high priority task, but > just exactly how broken is it? I mount most of my logical DOS drives > ro out of paranoia, but I've got one small throw-away partition > mounted rw for pushing things over to the Win95 world. I keep waiting > for it to eat my data, and it hasn't happened yet. > > I would like to see Win95 long filename support, and I'd be willing > to work on that, but are there more fundamental flaws that I'm > missing? As of the 2.x releases, mounting MS-DOS partitions should not cause wholescale corruption, and the present msdosfs works reasonably well for simple operations. It is fairly old and generally buggy, though. I have a new DOS filesystem, with Win95 support, running here, though some of the code is still alpha-quality, and I have literally not looked at it for several months, due to pressure of work. Once I can find a week or two, I want to look at cleaning this up for release. However (that said) I think it would be a good thing if anyone keen on working on adding Win95 to the msdosfs went ahead. The new DOS FS has been a very long time coming, and I'm sure many peope would appreciate the LFN support. -- Robert Nordier From owner-freebsd-fs Sat Aug 30 16:42:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA07981 for fs-outgoing; Sat, 30 Aug 1997 16:42:36 -0700 (PDT) Received: from serge.jbj.org (serge.JBJ.ORG [198.178.231.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA07975 for ; Sat, 30 Aug 1997 16:42:31 -0700 (PDT) Received: (from serge@localhost) by serge.jbj.org (8.8.6/8.6.12) id TAA01102; Sat, 30 Aug 1997 19:42:29 -0400 (EDT) Date: Sat, 30 Aug 1997 19:42:29 -0400 (EDT) Message-Id: <199708302342.TAA01102@serge.jbj.org> From: Serge Pashenkov To: freebsd-fs@freebsd.org Subject: NFS panic whith stale file handle Sender: owner-freebsd-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Haven't found NFS mailing list, so using this one, hope it's OK. Please tell me where it should go if this is a wrong place. My FreeBSD 2.2-STABLE machine panics while doing df if one of the NFS mount points became stale. Panic happens in nfs_statfs on the line marked <===============, where sfp is NULL. I'm not sure how it could get there with NULL value, but I'm not very good at nfsm_ macros. int nfs_statfs(mp, sbp, p) struct mount *mp; register struct statfs *sbp; struct proc *p; { register struct vnode *vp; register struct nfs_statfs *sfp; register caddr_t cp; register u_long *tl; register long t1, t2; caddr_t bpos, dpos, cp2; struct nfsmount *nmp = VFSTONFS(mp); int error = 0, v3 = (nmp->nm_flag & NFSMNT_NFSV3), retattr; struct mbuf *mreq, *mrep, *md, *mb, *mb2; struct ucred *cred; struct nfsnode *np; u_quad_t tquad; #ifndef nolint sfp = (struct nfs_statfs *)0; #endif error = nfs_nget(mp, (nfsfh_t *)nmp->nm_fh, nmp->nm_fhsize, &np); if (error) return (error); vp = NFSTOV(np); cred = crget(); cred->cr_ngroups = 1; if (v3 && (nmp->nm_flag & NFSMNT_GOTFSINFO) == 0) (void)nfs_fsinfo(nmp, vp, cred, p); nfsstats.rpccnt[NFSPROC_FSSTAT]++; nfsm_reqhead(vp, NFSPROC_FSSTAT, NFSX_FH(v3)); nfsm_fhtom(vp, v3); nfsm_request(vp, NFSPROC_FSSTAT, p, cred); if (v3) nfsm_postop_attr(vp, retattr); if (!error) nfsm_dissect(sfp, struct nfs_statfs *, NFSX_STATFS(v3)); #ifdef __NetBSD__ #ifdef COMPAT_09 sbp->f_type = 2; #else sbp->f_type = 0; #endif #else sbp->f_type = MOUNT_NFS; #endif sbp->f_flags = nmp->nm_flag; sbp->f_iosize = nfs_iosize(nmp); if (v3) { sbp->f_bsize = NFS_FABLKSIZE; fxdr_hyper(&sfp->sf_tbytes, &tquad); <=============== sbp->f_blocks = (long)(tquad / ((u_quad_t)NFS_FABLKSIZE)); fxdr_hyper(&sfp->sf_fbytes, &tquad); sbp->f_bfree = (long)(tquad / ((u_quad_t)NFS_FABLKSIZE)); fxdr_hyper(&sfp->sf_abytes, &tquad); sbp->f_bavail = (long)(tquad / ((u_quad_t)NFS_FABLKSIZE)); sbp->f_files = (fxdr_unsigned(long, sfp->sf_tfiles.nfsuquad[1]) & 0x7fffffff); sbp->f_ffree = (fxdr_unsigned(long, sfp->sf_ffiles.nfsuquad[1]) & 0x7fffffff); } else { sbp->f_bsize = fxdr_unsigned(long, sfp->sf_bsize); sbp->f_blocks = fxdr_unsigned(long, sfp->sf_blocks); sbp->f_bfree = fxdr_unsigned(long, sfp->sf_bfree); sbp->f_bavail = fxdr_unsigned(long, sfp->sf_bavail); sbp->f_files = 0; sbp->f_ffree = 0; } if (sbp != &mp->mnt_stat) { bcopy(mp->mnt_stat.f_mntonname, sbp->f_mntonname, MNAMELEN); bcopy(mp->mnt_stat.f_mntfromname, sbp->f_mntfromname, MNAMELEN); } nfsm_reqdone; vput(vp); crfree(cred); return (error); } Here is snoop output on the NFS exchange between the machines, which seems pretty normal to me: NFS: ----- Sun NFS ----- NFS: NFS: Proc = 19 (Get filesystem information) NFS: File handle = 0080001600000002000A000000000002 NFS: 737B83D0 NFS: NFS: ----- Sun NFS ----- NFS: NFS: Proc = 19 (Get filesystem information) NFS: Status = 70 (Stale NFS file handle) NFS: Post-operation attributes: (not available) NFS: NFS: ----- Sun NFS ----- NFS: NFS: Proc = 18 (Get filesystem statistics) NFS: File handle = 0080001600000002000A000000000002 NFS: 737B83D0 NFS: NFS: ----- Sun NFS ----- NFS: NFS: Proc = 18 (Get filesystem statistics) NFS: Status = 70 (Stale NFS file handle) NFS: Post-operation attributes: (not available) NFS: Thanks, serge