multiple mounts of single device
Hi, I've been searching for info regarding mounting the same device to multiple locations in the filesystem, i.e... # mount /dev/ad0s1e /usr # mount -r /dev/ad0s1e /var/jail//usr # mount -r /dev/ad0s1e /var/jail//usr [Warning: I /know/ I know next-to-nothing about filesystems... but] I recall seeing some traffic (IIRC, from early 2001) about this ability being in -current, but looking at HEAD:/usr/sys/ufs/ffs/ffs_vfsops.c, I still see around line 571 that EBUSY is still being returned if the device is already mounted. Not being familiar with the fbsd code... Am I even in the correct ballpark? Or is this functionality already present in -current? If it is already in -current, where would I start digging around if I felt like (breaking a perfectly good 4.5 install and) trying to integrate the -current code into 4.5? I'd especially appreciate any two minute (or less) response to any of the following questions -- I'm perfectly comfortable being told go away and read, if I have some idea of what to read. 0) Is this multiple mount point functionality even necessary, or is there a better/existing mechanism to achieve the same goal (aside from local nfs mount). 1) What is the danger of not failing with EBUSY if the device is already mounted? 2) Would supporting multiple mounts require modifying any code outside the filesystem (/usr/sys/src/ufs/ffs)? If so, how much and where? thanks. brent -- Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing. -- Duane Allman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote: | | Assignment: | | The v_tag element in struct vnode is a debugging aid, but unfortunately | it is implemented in a way which means that adding a filesystem means | modifying the definition in sys/vnode.h. | | Convert the v_tag to an const char * and have the filesystems put | their name in there instead. | | The v_tag has been abused a few places, easily recognizable by the fact | that the kernel should never inspect the value of v_tag. | These places should be easily changeable to use the new representation. | Please mark them with a big fat /*XXX: ABUSE OF v_tag */ comment. #include newbie_kernel_hacker_warning.h I've done a /cursory/ look over how this v_tag is used. I'm not sure this is a simple/clean as you propose, since this is used in the IS_LOCKING_VFS macro, as well as in union_subr.c... These uses /seem/ fairly significant due to the fact that the v_tag is being used to determine capabilities of the vnode in question. How should this be worked around? It would be fairly trivial to change v_tag to v_feature (or similar) then add the v_tag as you propose. I suggest this since those _tests_ for features should IMO not be done with a char[] operation, since that would (in my ignorant estimation) have a very negative effect on fs performance. Of course, my suggested v_feature hack would again require changing vnode.h for new features, but this is (assumedly) less frequent than modifying for file systems. I'll work on this this weekend, and (hopefully) follow thru with a patch. cheers. Brent -- Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing. -- Duane Allman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On 15 Jun 2001 at 00:38 (-0500), Stephen Montgomery-Smith wrote: | Mike Silbersack wrote: | | | Matt's performance manpage covers a lot of this, but is probably not as | easy to digest as an interactive script. | | | What do I type to read this man page? $ man tuning To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
gcc (cpp) include search path problem
Hi, I'm not sure if this has been the default for gcc/cpp on FBSD for a while but I noticed it since some ports failed to build due to includes (present in /usr/local/include) not being found. Has this changed, or is that port (wget) just broken. IMO, the search path for cpp should include /usr/local/include, especially since we install ports there. Brent colo:~/ brent$ cpp -v Using builtin specs. gcc version 2.95.3 [FreeBSD] 20010315 (release) /usr/libexec/cpp -lang-c -v -Di386 -D__FreeBSD__=4 -D__FreeBSD_cc_version=43 -Dunix -D__i386__ -D__FreeBSD__=4 -D__FreeBSD_cc_version=43 -D__unix__ -D__i386 -D__unix -Acpu(i386) -Amachine(i386) -Asystem(unix) -Asystem(FreeBSD) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__ELF__ - GNU CPP version 2.95.3 [FreeBSD] 20010315 (release) (i386 FreeBSD/ELF) #include ... search starts here: #include ... search starts here: /usr/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/include/g++ End of omitted list. ^C colo:~/ brent$ uname -a FreeBSD colo.rcfile.org 4.3-STABLE FreeBSD 4.3-STABLE #15: Wed May 23 17:39:35 EDT 2001 [EMAIL PROTECTED]:/usr/local/usr.obj/usr/src/sys/COLO i386 -- - - - - - -=( d a m o n b r e n t v e r n e r )=- - - - - - - c e r t i f i e d n o s o u r c o p h o b i c To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
