Re: mount -o union broken recently?
i just experienced the above today while trying diskless, and while ls only seems to return the entries for the topmost directory, files are accessible if you know the name. no idea if this is of any help. This is exactly the right pointer, thanks! The problem appears to be great -- will try this later today! so... should i bug someone to have this committed back to the tree (or ask permission to do it myself) ? cheers luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
On Fri, Feb 26, 1999 at 09:16:44PM +0100, Luigi Rizzo wrote: (about union mounts on 3.1 not returning all files with an 'ls' in 3.1 while it did in 3.0) Is it sorrect that this magic is implemented in sys/kern/vfs_lookup.c? The odd thing is that AFAICS no-one has made significant changes to this code. i just experienced the above today while trying diskless, and while ls only seems to return the entries for the topmost directory, files are accessible if you know the name. no idea if this is of any help. on a related subject; i noticed that using mount_null on a directory with device entries (e.g. still in the diskless case, say /foo/dev is an mfs partition with device entries, and i do a mount_null /foo/dev /dev ) causes very bad effects such as crashing the system when i start X. ideas about this as well ? Yes. NULLFS mounts do not work, due to a combination of aliasing problems and locking problems. There is a preliminary patch at http://www.freebsd.org/~eivind/FixNULL.patch that I believe fix the aliasing problems, and some of the locking problems, but not all. Using nullfs with this works somewhat, but sometimes get locks screwed up (which result in access to one file just hanging). Eivind. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
Julian Elischer jul...@whistle.com wrote:
On Fri, 26 Feb 1999, John Polstra wrote:
Julian Elischer wrote:
you want to commit?
(after you sir...)
No, really, after you ... :-)
Done
in 3.1 and 4
I just remembered that MNT_UNION occurs in another file which on
investigation turned out to be amongst the unionfs code that was
moved. It should be removed so that the code isn't run twice when
unionfs is enabled. Sorry for missing it the first time round! I also
tidied up the vfs_syscalls patch a bit.
Tony.
--
f.a.n.finch d...@dotat.at f...@demon.net
--- miscfs/union/union_subr.c.3.1 Sat Feb 27 20:44:14 1999
+++ miscfs/union/union_subr.c Sat Feb 27 20:47:28 1999
@@ -1183,15 +1183,6 @@
return -1; /* goto unionread */
}
}
- if (((*vp)-v_flag VROOT) ((*vp)-v_mount-mnt_flag MNT_UNION)) {
- struct vnode *tvp = *vp;
- *vp = (*vp)-v_mount-mnt_vnodecovered;
- VREF(*vp);
- fp-f_data = (caddr_t) *vp;
- fp-f_offset = 0;
- vrele(tvp);
- return -1; /* goto unionread */
- }
return error;
}
--- kern/vfs_syscalls.c.3.2 Sat Feb 27 20:55:32 1999
+++ kern/vfs_syscalls.c Sat Feb 27 21:00:26 1999
@@ -2756,23 +2756,24 @@
VOP_UNLOCK(vp, 0, p);
if (error)
return (error);
- if (union_dircheckp SCARG(uap, count) == auio.uio_resid) {
- error = union_dircheckp(p, vp, fp);
- if (error == -1)
+ if (SCARG(uap, count) == auio.uio_resid) {
+ if (union_dircheckp) {
+ error = union_dircheckp(p, vp, fp);
+ if (error == -1)
+ goto unionread;
+ if (error)
+ return (error);
+ }
+ if ((vp-v_flag VROOT)
+ (vp-v_mount-mnt_flag MNT_UNION)) {
+ struct vnode *tvp = vp;
+ vp = vp-v_mount-mnt_vnodecovered;
+ VREF(vp);
+ fp-f_data = (caddr_t) vp;
+ fp-f_offset = 0;
+ vrele(tvp);
goto unionread;
- if (error)
- return (error);
- }
- if ((SCARG(uap, count) == auio.uio_resid)
- (vp-v_flag VROOT)
- (vp-v_mount-mnt_flag MNT_UNION)) {
- struct vnode *tvp = vp;
- vp = vp-v_mount-mnt_vnodecovered;
- VREF(vp);
- fp-f_data = (caddr_t) vp;
- fp-f_offset = 0;
- vrele(tvp);
- goto unionread;
+ }
}
error = copyout((caddr_t)loff, (caddr_t)SCARG(uap, basep),
sizeof(long));
@@ -2833,23 +2834,24 @@
VOP_UNLOCK(vp, 0, p);
if (error)
return (error);
- if (union_dircheckp SCARG(uap, count) == auio.uio_resid) {
- error = union_dircheckp(p, vp, fp);
- if (error == -1)
+ if (SCARG(uap, count) == auio.uio_resid) {
+ if (union_dircheckp) {
+ error = union_dircheckp(p, vp, fp);
+ if (error == -1)
+ goto unionread;
+ if (error)
+ return (error);
+ }
+ if ((vp-v_flag VROOT)
+ (vp-v_mount-mnt_flag MNT_UNION)) {
+ struct vnode *tvp = vp;
+ vp = vp-v_mount-mnt_vnodecovered;
+ VREF(vp);
+ fp-f_data = (caddr_t) vp;
+ fp-f_offset = 0;
+ vrele(tvp);
goto unionread;
- if (error)
- return (error);
- }
- if ((SCARG(uap, count) == auio.uio_resid)
- (vp-v_flag VROOT)
- (vp-v_mount-mnt_flag MNT_UNION)) {
- struct vnode *tvp = vp;
- vp = vp-v_mount-mnt_vnodecovered;
- VREF(vp);
- fp-f_data = (caddr_t) vp;
- fp-f_offset = 0;
- vrele(tvp);
- goto unionread;
+ }
}
if (SCARG(uap, basep) != NULL) {
error = copyout((caddr_t)loff, (caddr_t)SCARG(uap, basep),
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
Julian Elischer jul...@whistle.com wrote: On Thu, 25 Feb 1999, John Polstra wrote: [...] Here, you did the union mount on top of an existing mount point (da1). I don't know for sure, but I suspect that this is the only case in which union mounts are designed to work. I was led to believe (last time I read the code) that any directory should be ok for a union mount I was led to believe the same by the manual: union Causes the namespace at the mount point to appear as the union of the mounted filesystem root and the existing di- rectory. Lookups will be done in the mounted filesystem first. If those operations fail due to a non-existent file the underlying directory is then accessed. All cre- ates are done in the mounted filesystem. I did a brief experiment on the 3.0-RELEASE machine as follows: # mount /dev/da0s1a on / (local, writes: sync 1163 async 18438) procfs on /proc (local) /dev/da0s1e on /usr (local, writes: sync 363 async 41653) /dev/da1s1e on /www/da1 (local, writes: sync 12 async 38) # ls da1/subdir this_is_da1 # mount -o union /dev/da2s1e da1/subdir # ls da1/subdir this_is_da1 this_is_da2 # So that machine is happy enough with union nounts on top of subdirectories. On the 3.1-STABLE machine, I tried union mounting on top of a mount point: # mount /dev/da0s1a on / (local, writes: sync 9824 async 55852) /dev/da0s1e on /www (local, writes: sync 5484 async 10400) procfs on /proc (local) /dev/da0s1f on /srcdelta (local, writes: sync 2569 async 2659) # ls /srcdelta thing # ls /www apache obj # umount /srcdelta # mount -o union /dev/da0s1f /www # ls /www thing # Still no joy. Is it sorrect that this magic is implemented in sys/kern/vfs_lookup.c? The odd thing is that AFAICS no-one has made significant changes to this code. Tony. -- f.a.n.finch d...@dotat.at f...@demon.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
(about union mounts on 3.1 not returning all files with an 'ls' in 3.1 while it did in 3.0) Is it sorrect that this magic is implemented in sys/kern/vfs_lookup.c? The odd thing is that AFAICS no-one has made significant changes to this code. i just experienced the above today while trying diskless, and while ls only seems to return the entries for the topmost directory, files are accessible if you know the name. no idea if this is of any help. on a related subject; i noticed that using mount_null on a directory with device entries (e.g. still in the diskless case, say /foo/dev is an mfs partition with device entries, and i do a mount_null /foo/dev /dev ) causes very bad effects such as crashing the system when i start X. ideas about this as well ? luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
Luigi Rizzo lu...@labinfo.iet.unipi.it wrote:
(about union mounts on 3.1 not returning all files with an 'ls' in
3.1 while it did in 3.0)
Is it sorrect that this magic is implemented in sys/kern/vfs_lookup.c?
The odd thing is that AFAICS no-one has made significant changes to
this code.
i just experienced the above today while trying diskless, and while
ls only seems to return the entries for the topmost directory, files
are accessible if you know the name. no idea if this is of any help.
This is exactly the right pointer, thanks! The problem appears to be
the change between revs 1.108 and 1.109 of sys/kern/vfs_syscalls.c. A
couple of (very similar) blocks of code related to `mount -o union`
seem to have been mixed up with some code related to `mount -t union`
and therefore removed. It's a shame that the two things get confused
so much. I originally missed vfs_syscalls.c because a `find
/usr/src/sys | xargs grep MNT_UNION` on 3.1 didn't show it. Replacing
the errant code fixes the problem. Here's a patch against 1.112.2.1.
Tony.
--
f.a.n.finch d...@dotat.at f...@demon.net
--- vfs_syscalls.c.3.1 Sat Feb 27 02:15:13 1999
+++ vfs_syscalls.c Sat Feb 27 02:30:42 1999
@@ -2763,6 +2763,17 @@
if (error)
return (error);
}
+ if ((SCARG(uap, count) == auio.uio_resid)
+ (vp-v_flag VROOT)
+ (vp-v_mount-mnt_flag MNT_UNION)) {
+ struct vnode *tvp = vp;
+ vp = vp-v_mount-mnt_vnodecovered;
+ VREF(vp);
+ fp-f_data = (caddr_t) vp;
+ fp-f_offset = 0;
+ vrele(tvp);
+ goto unionread;
+ }
error = copyout((caddr_t)loff, (caddr_t)SCARG(uap, basep),
sizeof(long));
p-p_retval[0] = SCARG(uap, count) - auio.uio_resid;
@@ -2828,6 +2839,17 @@
goto unionread;
if (error)
return (error);
+ }
+ if ((SCARG(uap, count) == auio.uio_resid)
+ (vp-v_flag VROOT)
+ (vp-v_mount-mnt_flag MNT_UNION)) {
+ struct vnode *tvp = vp;
+ vp = vp-v_mount-mnt_vnodecovered;
+ VREF(vp);
+ fp-f_data = (caddr_t) vp;
+ fp-f_offset = 0;
+ vrele(tvp);
+ goto unionread;
}
if (SCARG(uap, basep) != NULL) {
error = copyout((caddr_t)loff, (caddr_t)SCARG(uap, basep),
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
In article e10gzo8-0003ko...@fanf.noc.demon.net, Tony Finch d...@dotat.at wrote: Luigi Rizzo lu...@labinfo.iet.unipi.it wrote: i just experienced the above today while trying diskless, and while ls only seems to return the entries for the topmost directory, files are accessible if you know the name. no idea if this is of any help. This is exactly the right pointer, thanks! The problem appears to be the change between revs 1.108 and 1.109 of sys/kern/vfs_syscalls.c. A couple of (very similar) blocks of code related to `mount -o union` seem to have been mixed up with some code related to `mount -t union` and therefore removed. It's a shame that the two things get confused so much. I originally missed vfs_syscalls.c because a `find /usr/src/sys | xargs grep MNT_UNION` on 3.1 didn't show it. Replacing the errant code fixes the problem. Here's a patch against 1.112.2.1. Great sleuthing, guys! John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
you want to commit? (after you sir...) julian On Fri, 26 Feb 1999, John Polstra wrote: In article e10gzo8-0003ko...@fanf.noc.demon.net, Tony Finch d...@dotat.at wrote: Luigi Rizzo lu...@labinfo.iet.unipi.it wrote: i just experienced the above today while trying diskless, and while ls only seems to return the entries for the topmost directory, files are accessible if you know the name. no idea if this is of any help. This is exactly the right pointer, thanks! The problem appears to be the change between revs 1.108 and 1.109 of sys/kern/vfs_syscalls.c. A couple of (very similar) blocks of code related to `mount -o union` seem to have been mixed up with some code related to `mount -t union` and therefore removed. It's a shame that the two things get confused so much. I originally missed vfs_syscalls.c because a `find /usr/src/sys | xargs grep MNT_UNION` on 3.1 didn't show it. Replacing the errant code fixes the problem. Here's a patch against 1.112.2.1. Great sleuthing, guys! John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
Julian Elischer wrote: you want to commit? (after you sir...) No, really, after you ... :-) Seriously, I don't know the code in question very well. I'd rather not commit it myself. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
On Fri, 26 Feb 1999, John Polstra wrote: Julian Elischer wrote: you want to commit? (after you sir...) No, really, after you ... :-) Done in 3.1 and 4 julian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
In article e10fg4c-00013j...@fanf.noc.demon.net, Tony Finch d...@dotat.at wrote: I have been experimenting with union mounts today with a recent -stable (cvsupped yesterday), and I haven't had much luck. Because cvsup likes to obliterate local changes, You might wish to CVSup the repository itself (not use checkout mode), and then apply the techniques described in the CVSup FAQ to maintain your local changes. You can find the CVSup FAQ at http://www.polstra.com/projects/freeware/CVSup/. I've never messed with mount -o union before. But looking at the tests you did, I'm not so sure you've drawn the right conclusions. Here's your test that failed: # mount /dev/da0s1a on / (local, writes: sync 420 async 3185) procfs on /proc (local) /dev/da0s1e on /www (local, writes: sync 2 async 0) # mount /dev/da0s1f /srcdelta # ls -l /srcdelta total 1 drwxr-xr-x 6 root wheel 512 Feb 18 10:32 sys # umount /srcdelta # ls /usr/src COPYRIGHT UPDATING include share CVS bin kerberosIVsys Makefile contrib lib tools Makefile.inc0 cryptolibexec usr.bin Makefile.inc1 etc release usr.sbin Makefile.upgrade games sbin READMEgnu secure # mount -o union /dev/da0s1f /usr/src # ls -l /usr/src total 1 drwxr-xr-x 6 root wheel 512 Feb 18 10:32 sys # umount /usr/src # uname -a FreeBSD shirt.www.demon.net 3.1-STABLE FreeBSD 3.1-STABLE #6: Thu Feb 18 02:26:59 GMT 1999 r...@shirt.www.demon.net:/usr/src/sys/compile/SHIRT i386 # OK, in that test, you did the union mount onto /usr/src, which was _not_ a mount point. But you did something different in the test that succeeded: However, on another machine running 3.0-RELEASE mount -o union works as expected: # ls -l total 6 drwxr-xr-x 2 root wheel 512 Feb 18 16:36 da1 drwxr-xr-x 2 root wheel 512 Dec 11 11:06 da2 # mount /dev/da1s1e da1 # mount /dev/da2s1e da2 # ls -l da?/* -rw-r--r-- 1 root wheel 0 Feb 18 16:36 da1/this_is_da1 -rw-r--r-- 1 root wheel 0 Feb 18 16:36 da2/this_is_da2 # umount da2 # mount -o union /dev/da2s1e /www/da1 # ls -l da?/* -rw-r--r-- 1 root wheel 0 Feb 18 16:36 da1/this_is_da1 -rw-r--r-- 1 root wheel 0 Feb 18 16:36 da1/this_is_da2 # Here, you did the union mount on top of an existing mount point (da1). I don't know for sure, but I suspect that this is the only case in which union mounts are designed to work. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
On Thu, 25 Feb 1999, John Polstra wrote: [...] Here, you did the union mount on top of an existing mount point (da1). I don't know for sure, but I suspect that this is the only case in which union mounts are designed to work. I was led to believe (last time I read the code) that any directory should be ok for a union mount julian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
mount -o union broken recently?
I have been experimenting with union mounts today with a recent -stable (cvsupped yesterday), and I haven't had much luck. Because cvsup likes to obliterate local changes, I thought it would be convenient to keep the altered files on a separate filesystem and use a union mount to overlay them on the upstream source when I compile things. So: # mount /dev/da0s1a on / (local, writes: sync 420 async 3185) procfs on /proc (local) /dev/da0s1e on /www (local, writes: sync 2 async 0) # mount /dev/da0s1f /srcdelta # ls -l /srcdelta total 1 drwxr-xr-x 6 root wheel 512 Feb 18 10:32 sys # umount /srcdelta # ls /usr/src COPYRIGHT UPDATING include share CVS bin kerberosIVsys Makefile contrib lib tools Makefile.inc0 cryptolibexec usr.bin Makefile.inc1 etc release usr.sbin Makefile.upgrade games sbin READMEgnu secure # mount -o union /dev/da0s1f /usr/src # ls -l /usr/src total 1 drwxr-xr-x 6 root wheel 512 Feb 18 10:32 sys # umount /usr/src # uname -a FreeBSD shirt.www.demon.net 3.1-STABLE FreeBSD 3.1-STABLE #6: Thu Feb 18 02:26:59 GMT 1999 r...@shirt.www.demon.net:/usr/src/sys/compile/SHIRT i386 # However, on another machine running 3.0-RELEASE mount -o union works as expected: # ls -l total 6 drwxr-xr-x 2 root wheel 512 Feb 18 16:36 da1 drwxr-xr-x 2 root wheel 512 Dec 11 11:06 da2 # mount /dev/da1s1e da1 # mount /dev/da2s1e da2 # ls -l da?/* -rw-r--r-- 1 root wheel 0 Feb 18 16:36 da1/this_is_da1 -rw-r--r-- 1 root wheel 0 Feb 18 16:36 da2/this_is_da2 # umount da2 # mount -o union /dev/da2s1e /www/da1 # ls -l da?/* -rw-r--r-- 1 root wheel 0 Feb 18 16:36 da1/this_is_da1 -rw-r--r-- 1 root wheel 0 Feb 18 16:36 da1/this_is_da2 # Shirt's kernel configuration is below. Tony. -- f.a.n.finch d...@dotat.at f...@demon.net machine i386 cpu I686_CPU ident SHIRT maxusers64 options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options MFS #Memory Filesystem #optionsMFS_ROOT#MFS usable as root device, MFS req'ed options NFS #Network Filesystem options NFS_NOSERVER #optionsNFS_ROOT#NFS usable as root device, NFS req'ed options MSDOSFS #MSDOS Filesystem #optionsCD9660#ISO 9660 Filesystem #optionsCD9660_ROOT #CD-ROM usable as root. CD9660 req'ed options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=1000 #Be pessimistic about Joe SCSI device options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options NETALIAS options NETBIND options SOFTUPDATES options MAXMEM=(64*1024) options PQ_MEDIUMCACHE options INCLUDE_CONFIG_FILE options PERFMON options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_DEFAULT_TO_ACCEPT options ICMP_BANDLIM options DUMMYNET config kernel root on wd0 controller isa0 controller eisa0 controller pci0 controller fdc0at isa? port IO_FD1 bio irq 6 drq 2 diskfd0 at fdc0 drive 0 #disk fd1 at fdc0 drive 1 options CMD640# work around CMD640 chip deficiency controller wdc0at isa? port IO_WD1 bio irq 14 diskwd0 at wdc0 drive 0 options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC#Don't do it as an LKM device acd0#IDE CD-ROM controller ncr0 controller scbus0 device da0 device pass0 device cd0 #Only need one of these, the code dynamically grows # atkbdc0 controlls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device psm0at isa? tty irq 12 device vga0at isa? port ? conflicts # splash screen/screen saver #pseudo-device splash #optionsVM86 #optionsVESA # syscons is the default console driver, resembling an SCO console device sc0 at isa? tty device npx0at isa? port IO_NPX irq 13 # Laptop support (see LINT for more options) # device apm0at isa? disable flags 0x31 # Advanced Power Management # serial port device
