From owner-freebsd-fs Sun Nov 19 0:59:13 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 9BDF237B4C5 for ; Sun, 19 Nov 2000 00:59:08 -0800 (PST) Received: from victoria-088.budapest.interware.hu ([195.70.63.88] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13xQJV-0003lL-00; Sun, 19 Nov 2000 09:59:05 +0100 Message-ID: <3A179656.CA555A2B@elischer.org> Date: Sun, 19 Nov 2000 00:59:02 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: dwalton@acm.org Cc: fs@freebsd.org Subject: Re: corrupted filesystem References: <3A16FE71.20481.69FB69@localhost> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dave Walton wrote: > > Boy have I got a stinker of a mess. A server crashed, apparently > due to a power supply problem, and messed up its filesystem > pretty thoroughly. I need some help digging through the piles of > bits. (As an aside, I'd had the notion that only open files were at > risk for corruption. These problems seem more widespread than > that. Why might that be? Would softupdates have prevented the > problem?) probably. Soft updates would have limitted he damage to files created/extended in the last 30 seconds. > > > ------------------------------------------------------------ > /mnt# ls -alF > ls: libdata: Bad file descriptor > ls: local: Bad file descriptor > ls: share: Bad file descriptor > ls: src: Bad file descriptor > total 1235043903 > drwxr-xr-x 17 root wheel 512 Aug 24 23:45 ./ > drwxr-xr-x 15 root wheel 512 Nov 18 02:29 ../ > drwxr-xr-x 2 root wheel 6656 Aug 25 06:07 > bin/ > drwxr-xr-x 3 root wheel 512 Aug 23 19:17 > compat/ > drwxr-xr-x 3 root wheel 1024 Aug 23 18:26 > games/ > -rws-w--wx 32458 389421524 3725029886 > 7966077931114349813 Jan 30 2022 home* > drwxr-xr-x 35 root wheel 3072 Aug 24 05:55 > include/ > drwxr-xr-x 4 root wheel 6656 Aug 24 05:57 > lib/ > drwxr-xr-x 8 root wheel 1024 Aug 24 05:57 > libexec/ > drwxr-xr-x 3 root wheel 512 Aug 24 23:57 > obj/ > drwxr-xr-x 51 root wheel 1024 Aug 23 18:47 > ports/ > -rw-r----- 1 root operator 2097120 Nov 17 04:23 > quota.group > -rw-r----- 1 root operator 2097120 Nov 17 04:23 > quota.user > drwxr-xr-x 2 root wheel 4096 Aug 25 06:07 > sbin/ > drwxrwxrwt 3 root wheel 1536 Nov 16 10:08 > tmp/ > /mnt# > ------------------------------------------------------------ > > By some magic, home has become a regular file instead of a dir! > Well, that won't do at all, because that is the place I most need to > get to. So I gritted my teeth and fired up fsdb (first time ever) to > have a look-see: > > ------------------------------------------------------------ > /# fsdb -r /dev/rda0s1f > ** /dev/rda0s1f (NO WRITE) > Examining file system `/dev/rda0s1f' > Last Mounted on /usr > current inode: directory > I=2 MODE=40755 SIZE=512 > MTIME=Aug 24 23:45:30 2000 [0 nsec] > CTIME=Aug 24 23:45:30 2000 [0 nsec] > ATIME=Nov 17 00:25:04 2000 [0 nsec] > OWNER=root GRP=wheel LINKCNT=17 FLAGS=0 BLKCNT=2 > GEN=6f7bd28 > fsdb (inum: 2)> ls > slot 0 ino 2 reclen 12: directory, `.' > slot 1 ino 2 reclen 12: directory, `..' > slot 2 ino 7936 reclen 12: directory, `bin' > slot 3 ino 15872 reclen 16: directory, `include' > slot 4 ino 349184 reclen 12: directory, `lib' > slot 5 ino 380928 reclen 16: directory, `libdata' > slot 6 ino 1190400 reclen 16: directory, `libexec' > slot 7 ino 1253888 reclen 16: directory, `local' > slot 8 ino 1261824 reclen 16: directory, `sbin' > slot 9 ino 1269760 reclen 16: directory, `share' > slot 10 ino 3222016 reclen 12: directory, `src' > slot 11 ino 4063232 reclen 16: directory, `games' > slot 12 ino 1222148 reclen 16: directory, `ports' > slot 13 ino 15014935 reclen 16: directory, `compat' > slot 14 ino 15038738 reclen 12: directory, `obj' > slot 15 ino 15443479 reclen 12: directory, `tmp' > slot 16 ino 3039518 reclen 16: directory, `home' > slot 17 ino 27 reclen 20: regular, `quota.user' > slot 18 ino 28 reclen 248: regular, `quota.group' > fsdb (inum: 2)> cd home > component `home': current inode: regular file > I=3039518 MODE=104723 SIZE=7966077931114349813 > MTIME=Jan 30 19:02:03 2022 [2140389655 nsec] > CTIME=Nov 2 18:02:35 1975 [-556098662 nsec] > ATIME=Feb 7 04:40:01 2016 [374691499 nsec] > OWNUID=389421524 GID=3725029886 LINKCNT=32458 > FLAGS=0xb03ec3e0 BLKCNT=933a8bb1 GEN=7f060afc > fsdb (inum: 3039518)> > ------------------------------------------------------------ > > Ok, now I'm really confused! First fsdb reports home as a > directory, but when I cd into it, it becomes a regular file? How can > that be? no, it is still a regular file.. 'cd' in fsdb just makes it the 'current' inode. It's possible that the real inode is floating around somewhere, 'unattached'. or maybe the 'data' is correct but the inode is wrong. can you 'ls' it? > > So that's where I am. Any suggestions for getting into home are > most welcome. I have the feeling that home itself may be a lost > cause. How can I search for all directories that had home as a > parent and relink them somewhere else? Any other ideas? > > In summary.... HELP! :) > > Thanks for listening, > Dave > > ---------------------------------------------------------------------- > Dave Walton dwalton@acm.org > ---------------------------------------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Nov 19 3:53:41 2000 Delivered-To: freebsd-fs@freebsd.org Received: from modgud.nordicrecords.com (h21-168-107.nordicdms.com [207.21.168.107]) by hub.freebsd.org (Postfix) with SMTP id 02E9D37B479 for ; Sun, 19 Nov 2000 03:53:34 -0800 (PST) Received: (qmail 6874 invoked by alias); 19 Nov 2000 11:53:23 -0000 Received: (qmail 6861 invoked from network); 19 Nov 2000 11:53:22 -0000 Received: from adsl-216-103-90-137.dsl.snfc21.pacbell.net (HELO thinkpad770z) (216.103.90.137) by mail.nordicrecords.com with SMTP; 19 Nov 2000 11:53:22 -0000 From: "Dave Walton" To: Julian Elischer Date: Sun, 19 Nov 2000 03:53:09 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: corrupted filesystem Reply-To: dwalton@acm.org Cc: fs@freebsd.org Message-ID: <3A174EA5.24115.102AB11@localhost> In-reply-to: <3A179656.CA555A2B@elischer.org> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 19 Nov 2000, at 0:59, Julian Elischer wrote: > probably. Soft updates would have limitted he damage to files > created/extended in the last 30 seconds. Note to self: Remember to turn on softupdates. > Dave Walton wrote: > > ------------------------------------------------------------ > > fsdb (inum: 2)> ls > > slot 16 ino 3039518 reclen 16: directory, `home' > > fsdb (inum: 2)> cd home > > component `home': current inode: regular file > > ------------------------------------------------------------ > > > > Ok, now I'm really confused! First fsdb reports home as a > > directory, but when I cd into it, it becomes a regular file? How can > > that be? > > no, it is still a regular file.. > 'cd' in fsdb just makes it the 'current' inode. I understand that. But if you look at the short excerpt from fsdb above, it specifically says "directory" when I do ls. But after I cd to it, fsdb says "regular file". Quite a contradiction. > It's possible that the real inode is floating around somewhere, > 'unattached'. > or maybe the 'data' is correct but the inode is wrong. Either way, any tips for tracking down the real contents of home? > can you 'ls' it? Nope. It seems to act just like a normal file, except when I do an ls on it's parent in fsdb. Dave ---------------------------------------------------------------------- Dave Walton dwalton@acm.org ---------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Nov 19 5:37:18 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 19A4B37B479 for ; Sun, 19 Nov 2000 05:37:16 -0800 (PST) Received: from kinshasa-37.budapest.interware.hu ([195.70.51.165] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13xUef-0005KW-00; Sun, 19 Nov 2000 14:37:13 +0100 Message-ID: <3A17D787.68A9E27C@elischer.org> Date: Sun, 19 Nov 2000 05:37:11 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: dwalton@acm.org Cc: fs@freebsd.org Subject: Re: corrupted filesystem References: <3A174EA5.24115.102AB11@localhost> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dave Walton wrote: > > On 19 Nov 2000, at 0:59, Julian Elischer wrote: > > > probably. Soft updates would have limitted he damage to files > > created/extended in the last 30 seconds. > > Note to self: Remember to turn on softupdates. > > > Dave Walton wrote: > > > ------------------------------------------------------------ > > > fsdb (inum: 2)> ls > > > slot 16 ino 3039518 reclen 16: directory, `home' > > > fsdb (inum: 2)> cd home > > > component `home': current inode: regular file > > > ------------------------------------------------------------ > > > > > > Ok, now I'm really confused! First fsdb reports home as a > > > directory, but when I cd into it, it becomes a regular file? How can > > > that be? > > > > no, it is still a regular file.. > > 'cd' in fsdb just makes it the 'current' inode. > > I understand that. But if you look at the short excerpt from fsdb > above, it specifically says "directory" when I do ls. But after I cd to > it, fsdb says "regular file". Quite a contradiction. there is a file/dir bit in the directory as well obviously they disagree.. hopefully if you can run fsck -y you can find the inodes of the user's individual directories when they are put in lost+found > > > It's possible that the real inode is floating around somewhere, > > 'unattached'. > > or maybe the 'data' is correct but the inode is wrong. > > Either way, any tips for tracking down the real contents of home? > > > can you 'ls' it? > > Nope. It seems to act just like a normal file, except when I do an > ls on it's parent in fsdb. > > Dave > > ---------------------------------------------------------------------- > Dave Walton dwalton@acm.org > ---------------------------------------------------------------------- -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Nov 19 16:28:45 2000 Delivered-To: freebsd-fs@freebsd.org Received: from modgud.nordicrecords.com (h21-168-107.nordicdms.com [207.21.168.107]) by hub.freebsd.org (Postfix) with SMTP id 1379137B479 for ; Sun, 19 Nov 2000 16:28:43 -0800 (PST) Received: (qmail 9663 invoked by alias); 20 Nov 2000 00:28:39 -0000 Received: (qmail 9649 invoked from network); 20 Nov 2000 00:28:38 -0000 Received: from adsl-216-103-90-137.dsl.snfc21.pacbell.net (HELO thinkpad770z) (216.103.90.137) by mail.nordicrecords.com with SMTP; 20 Nov 2000 00:28:38 -0000 From: "Dave Walton" To: Julian Elischer , fs@freebsd.org Date: Sun, 19 Nov 2000 16:28:25 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: corrupted filesystem Reply-To: dwalton@acm.org Message-ID: <3A17FFA9.30580.3B5C5FD@localhost> In-reply-to: <3A17D787.68A9E27C@elischer.org> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 19 Nov 2000, at 5:37, Julian Elischer wrote: > there is a file/dir bit in the directory as well > obviously they disagree.. Ah. Now it makes sense. > hopefully if you can run fsck -y you can find the inodes of the > user's individual directories when they are put in lost+found Isn't it possible for fsck -y to cause more damage while it tries to repair things? Thanks, Dave ---------------------------------------------------------------------- Dave Walton dwalton@acm.org ---------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Nov 20 1: 1:16 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id E0BEB37B4C5 for ; Mon, 20 Nov 2000 01:01:12 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id CAA17847; Mon, 20 Nov 2000 02:01:49 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpdAAAwWaG1I; Mon Nov 20 02:01:41 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id CAA04577; Mon, 20 Nov 2000 02:01:03 -0700 (MST) From: Terry Lambert Message-Id: <200011200901.CAA04577@usr06.primenet.com> Subject: Re: corrupted filesystem To: dwalton@acm.org Date: Mon, 20 Nov 2000 09:01:03 +0000 (GMT) Cc: julian@elischer.org (Julian Elischer), fs@FreeBSD.ORG In-Reply-To: <3A17FFA9.30580.3B5C5FD@localhost> from "Dave Walton" at Nov 19, 2000 04:28:25 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > there is a file/dir bit in the directory as well > > obviously they disagree.. > > Ah. Now it makes sense. > > > hopefully if you can run fsck -y you can find the inodes of the > > user's individual directories when they are put in lost+found > > Isn't it possible for fsck -y to cause more damage while it tries to > repair things? It will probably delete everything as "unreferenced". It's pretty clear that your /usr directory got hosed, which probably means "/" on the FS being mounted as /usr. This will have happened because the directory entry block that was at the top level was undergoing modification at the time of the crash. The most likely reason for this was a create or a rename of a file or directory in /usr, resulting in a compaction of the directory entry block containing the damaged entries. You could "fix" this by dumping the contents of the top level directory on the device, and sifting through it by hand with a copy of /sys/ufs/ufs/dir.h in hand. "Fixed", you will have added back references to the inodes of the directories (and perhaps files, if there were any) under /usr. See the comments in the dir.h file referenced above for details on the layout of the inodes and what makes an inode "deleted" or still alive. If any of your entries are the first entry in a directory block, you are probably screwed for that entry, since the way a directory entry is deleted from the front of a block is to zero its inode number. The one exception to this will be the first one, since that entry will be for "." (and the next for ".."). As the root of a filesystem, we know that the inode there will be "2". Adjusting the d_type for the home directory should be easy. If the problem is the type on the inode itself, you are in much worse trouble, since this will mean that the inode that had the home directory in it has been subsequently reqused for a normal file, and the data is probably destroyed. This can also be recovered, with difficulty (you will probably need to write a specialized tool for this, unless you are willing to live with everything being place in lost+found). My suggestion would be to do an image backup of the FS to tape (preferrable, twice, just in case; that a hell of a lot of data) _NOW_, and that you do it _BEFORE_ you do anything else. Realize that your previous attempts at recovery, if an automatic recovery was attempted, may have damaged your data by clearing inodes that should not have been cleared. If during your manual fsck, you overrode the "no", you could likewise have damaged the data. As a general rule, fsck exists not to recover data, but to return the FS to a consistant state. It will likely recover all that it can to lost+found, but that may not be everything. What it does recover to lost+found will be inode number named directories and files. Since directories are recovered first, this should mean that subhierarchies underneath will remain intact, and all you will lose is the names of the directories. But beware: with a corrupt root inode, all bets are off: fsck will not be able to recover, since if / is not a directory, then it will not be able to create /lost+found within the FS. So your first order of business _MUST_ be to recover as much of your / on that device as possible, so that what isn't recovered by fixing that will be recoverable into a /lost+found which can be created by the fsck process. Generally, when I run ito this type of failure, I sit down on a different system and write some tools specific to the recovery task at hand; this can be a cluster-grep, a finder-of-directory-inodes (with non-zero reference counts), a simple raw directory editor, etc.: whatever is needed for the specific task. PS: Your job is going to be much harder, since block devices were murdered, so unless your system predated the murder, you will have to be very careful to only read and write in disk block sized units on disk block boundaries. For almost all disks, this will be 512b chunks on 512b boundaries. Emergency recovery was much easier before block devices were shot in the head. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Nov 20 6: 0:55 2000 Delivered-To: freebsd-fs@freebsd.org Received: from nil.science-factory.com (Sciencefactory-atm1-181.piro.net [195.135.137.205]) by hub.freebsd.org (Postfix) with ESMTP id 708EC37B4C5 for ; Mon, 20 Nov 2000 06:00:53 -0800 (PST) Received: (from mvw@localhost) by nil.science-factory.com (8.11.1/8.11.1) id eAKE0T613531; Mon, 20 Nov 2000 15:00:29 +0100 (CET) (envelope-from marc.vanwoerkom@science-factory.com) Date: Mon, 20 Nov 2000 15:00:29 +0100 (CET) Message-Id: <200011201400.eAKE0T613531@nil.science-factory.com> X-Authentication-Warning: nil.science-factory.com: mvw set sender to marc.vanwoerkom@science-factory.com using -f From: Marc van Woerkom To: freebsd-fs@freebsd.org Subject: MSDOS FS and flock? Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I wonder why Emacs' movemail program is not able to move mail on a MSDOS partion. Under Linux this seems to be no problem (or no visible problem yet :-) My guess is that msdosfs does not allow flock(). Questions: 1) Might this be true? And if yes, would flock()ing be necessary - the msdosfs code might do such already. 2) Does anyone have a patch to movemail or msdosfs? Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Nov 20 13:16:29 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id C541F37B4C5 for ; Mon, 20 Nov 2000 13:16:26 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id OAA15150; Mon, 20 Nov 2000 14:12:16 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAxOaqBD; Mon Nov 20 14:12:04 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA01210; Mon, 20 Nov 2000 14:16:09 -0700 (MST) From: Terry Lambert Message-Id: <200011202116.OAA01210@usr08.primenet.com> Subject: Re: MSDOS FS and flock? To: marc.vanwoerkom@science-factory.com (Marc van Woerkom) Date: Mon, 20 Nov 2000 21:16:08 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: <200011201400.eAKE0T613531@nil.science-factory.com> from "Marc van Woerkom" at Nov 20, 2000 03:00:29 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I wonder why Emacs' movemail program is not able to move > mail on a MSDOS partion. > Under Linux this seems to be no problem (or no visible > problem yet :-) > > My guess is that msdosfs does not allow flock(). > > Questions: > 1) Might this be true? > And if yes, would flock()ing be necessary - the > msdosfs code might do such already. > > 2) Does anyone have a patch to movemail or > msdosfs? The lock lists are hung off the in-core inode, not the vnode. This means that locking doesn't work, except on VFS that implement VOP_ADVLOCK by applying a lock to the underlying backing objects. This also means that, since a VOP_ADVLOCK entry is required, flock() doesn't work on FreeBSD on special devices, sockets, or named pipes (all of which have a struct fileops different from the standard VFS struct fileops), since the flock() entry point ignores everything but standard VFS'. The way to correct this is to move all but veto processing out of the per VFS code, and hang the lock list off the vnode instead (veto processing needs to remain to support coelesce across multiple stacking layers, as well as layers with multiple exposures, where the lock lists of two or more vnodes need to appear as a single lock space. This also implies that not only pid is needed to uniquify namespace, and system ID (for NFS support), but _also_ a VFS ID: otherwise there will be an erroneous attempt to coelesce locks from an upper layer in a lower layer, when the upper and lower layer are simultaneously exposed into the file system namespace, and locks are asserted into both layers (this is a detail that would prevent VFS stacking from working correctly, were it not implemented). What version of the OS are you running? I could provide a set of patches against 4.1, if you absolutely needed it, but I doubt it would be carried forward in FreeBSD -HEAD, which I have to say I'm not going to touch right now. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Nov 20 18:31:54 2000 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 58DF137B479 for ; Mon, 20 Nov 2000 18:31:49 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id 8BD2629114; Tue, 21 Nov 2000 08:31:46 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 7A72C28EA0; Tue, 21 Nov 2000 08:31:46 +0600 (ALMT) Date: Tue, 21 Nov 2000 08:31:46 +0600 (ALMT) From: Boris Popov To: Marc van Woerkom Cc: freebsd-fs@freebsd.org Subject: Re: MSDOS FS and flock? In-Reply-To: <200011201400.eAKE0T613531@nil.science-factory.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1004567761-974773906=:42711" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1004567761-974773906=:42711 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 20 Nov 2000, Marc van Woerkom wrote: > I wonder why Emacs' movemail program is not able to move > mail on a MSDOS partion. > Under Linux this seems to be no problem (or no visible > problem yet :-) > > My guess is that msdosfs does not allow flock(). Yes, msdosfs doesn't implement advisory locks. Attached you'll find a diff against recent -current (but should work on -stable too) which adds necessary VOP to msdosfs. -- Boris Popov http://www.butya.kz/~bp/ --0-1004567761-974773906=:42711 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="msdoslk.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="msdoslk.diff" SW5kZXg6IGRlbm9kZS5oDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1Mg ZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL21zZG9zZnMvZGVub2RlLmgsdg0K cmV0cmlldmluZyByZXZpc2lvbiAxLjIxDQpkaWZmIC11IC1yMS4yMSBkZW5v ZGUuaA0KLS0tIGRlbm9kZS5oCTIwMDAvMTAvMjIgMTQ6MjI6MTcJMS4yMQ0K KysrIGRlbm9kZS5oCTIwMDAvMTEvMTQgMDI6MDU6NDQNCkBAIC0xNjAsNiAr MTYwLDcgQEANCiAJdV9sb25nIGRlX0ZpbGVTaXplOwkvKiBzaXplIG9mIGZp bGUgaW4gYnl0ZXMgKi8NCiAJc3RydWN0IGZhdGNhY2hlIGRlX2ZjW0ZDX1NJ WkVdOwkvKiBmYXQgY2FjaGUgKi8NCiAJdV9xdWFkX3QgZGVfbW9kcmV2Owkv KiBSZXZpc2lvbiBsZXZlbCBmb3IgbGVhc2UuICovDQorCXN0cnVjdCBsb2Nr ZiAqZGVfbG9ja2Y7CS8qIExvY2tpbmcgcmVjb3JkIG9mIGZpbGUgKi8NCiB9 Ow0KIA0KIC8qDQpJbmRleDogbXNkb3Nmc192bm9wcy5jDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL21z ZG9zZnMvbXNkb3Nmc192bm9wcy5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24g MS4xMDYNCmRpZmYgLXUgLXIxLjEwNiBtc2Rvc2ZzX3Zub3BzLmMNCi0tLSBt c2Rvc2ZzX3Zub3BzLmMJMjAwMC8xMC8yMiAxNDoyNDozMAkxLjEwNg0KKysr IG1zZG9zZnNfdm5vcHMuYwkyMDAwLzExLzE0IDAyOjA5OjQyDQpAQCAtNTcs NiArNTcsNyBAQA0KICNpbmNsdWRlIDxzeXMvYmlvLmg+DQogI2luY2x1ZGUg PHN5cy9idWYuaD4NCiAjaW5jbHVkZSA8c3lzL3Byb2MuaD4NCisjaW5jbHVk ZSA8c3lzL2xvY2tmLmg+DQogI2luY2x1ZGUgPHN5cy9tb3VudC5oPg0KICNp bmNsdWRlIDxzeXMvdW5pc3RkLmg+DQogI2luY2x1ZGUgPHN5cy92bm9kZS5o Pg0KQEAgLTEwMyw2ICsxMDQsNyBAQA0KIHN0YXRpYyBpbnQgbXNkb3Nmc19w YXRoY29uZiBfX1AoKHN0cnVjdCB2b3BfcGF0aGNvbmZfYXJncyAqYXApKTsN CiBzdGF0aWMgaW50IG1zZG9zZnNfZ2V0cGFnZXMgX19QKChzdHJ1Y3Qgdm9w X2dldHBhZ2VzX2FyZ3MgKikpOw0KIHN0YXRpYyBpbnQgbXNkb3Nmc19wdXRw YWdlcyBfX1AoKHN0cnVjdCB2b3BfcHV0cGFnZXNfYXJncyAqKSk7DQorc3Rh dGljIGludCBtc2Rvc2ZzX2FkdmxvY2sgKHN0cnVjdCB2b3BfYWR2bG9ja19h cmdzICopOw0KIA0KIC8qDQogICogU29tZSBnZW5lcmFsIG5vdGVzOg0KQEAg LTE4ODAsNiArMTg4MiwyNSBAQA0KIH0NCiANCiAvKg0KKyAqIEFkdmlzb3J5 IGJ5dGUtbGV2ZWwgbG9ja3MuDQorICovDQorc3RhdGljIGludA0KK21zZG9z ZnNfYWR2bG9jayhhcCkNCisJc3RydWN0IHZvcF9hZHZsb2NrX2FyZ3MgLyog ew0KKwkJc3RydWN0IHZub2RlICphX3ZwOw0KKwkJY2FkZHJfdCAgYV9pZDsN CisJCWludCAgYV9vcDsNCisJCXN0cnVjdCBmbG9jayAqYV9mbDsNCisJCWlu dCAgYV9mbGFnczsNCisJfSAqLyAqYXA7DQorew0KKwlzdHJ1Y3QgZGVub2Rl ICpkZXAgPSBWVE9ERShhcC0+YV92cCk7DQorDQorCXJldHVybiAobGZfYWR2 bG9jayhhcCwgJmRlcC0+ZGVfbG9ja2YsIGRlcC0+ZGVfRmlsZVNpemUpKTsN Cit9DQorDQorDQorLyoNCiAgKiBwdXQgcGFnZSByb3V0aW5lDQogICoNCiAg KiBYWFggQnkgZGVmYXVsdCwgd2ltcCBvdXQuLi4gbm90ZSB0aGF0IGFfb2Zm c2V0IGlzIGlnbm9yZWQgKGFuZCBhbHdheXMNCkBAIC0xODk4LDYgKzE5MTks NyBAQA0KIHN0YXRpYyBzdHJ1Y3Qgdm5vZGVvcHZfZW50cnlfZGVzYyBtc2Rv c2ZzX3Zub2Rlb3BfZW50cmllc1tdID0gew0KIAl7ICZ2b3BfZGVmYXVsdF9k ZXNjLAkJKHZvcF90ICopIHZvcF9kZWZhdWx0b3AgfSwNCiAJeyAmdm9wX2Fj Y2Vzc19kZXNjLAkJKHZvcF90ICopIG1zZG9zZnNfYWNjZXNzIH0sDQorCXsg JnZvcF9hZHZsb2NrX2Rlc2MsCQkodm9wX3QgKikgbXNkb3Nmc19hZHZsb2Nr IH0sDQogCXsgJnZvcF9ibWFwX2Rlc2MsCQkodm9wX3QgKikgbXNkb3Nmc19i bWFwIH0sDQogCXsgJnZvcF9jYWNoZWRsb29rdXBfZGVzYywJKHZvcF90ICop IG1zZG9zZnNfbG9va3VwIH0sDQogCXsgJnZvcF9jbG9zZV9kZXNjLAkJKHZv cF90ICopIG1zZG9zZnNfY2xvc2UgfSwNCg== --0-1004567761-974773906=:42711-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Nov 21 2: 8:20 2000 Delivered-To: freebsd-fs@freebsd.org Received: from nil.science-factory.com (Sciencefactory-atm1-181.piro.net [195.135.137.205]) by hub.freebsd.org (Postfix) with ESMTP id C503437B4D7 for ; Tue, 21 Nov 2000 02:08:16 -0800 (PST) Received: (from mvw@localhost) by nil.science-factory.com (8.11.1/8.11.1) id eALA7j516571; Tue, 21 Nov 2000 11:07:45 +0100 (CET) (envelope-from marc.vanwoerkom@science-factory.com) Date: Tue, 21 Nov 2000 11:07:45 +0100 (CET) Message-Id: <200011211007.eALA7j516571@nil.science-factory.com> X-Authentication-Warning: nil.science-factory.com: mvw set sender to marc.vanwoerkom@science-factory.com using -f From: Marc van Woerkom To: tlambert@primenet.com Cc: marc.vanwoerkom@science-factory.com, freebsd-fs@FreeBSD.ORG In-reply-to: <200011202116.OAA01210@usr08.primenet.com> (message from Terry Lambert on Mon, 20 Nov 2000 21:16:08 +0000 (GMT)) Subject: Re: MSDOS FS and flock? References: <200011202116.OAA01210@usr08.primenet.com> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > What version of the OS are you running? I could provide a > set of patches against 4.1, if you absolutely needed it, Thanks for your generous offer. This would be far too much hassle, I think. The background is that I have three OS partions (FreeBSD-CURRENT, Linux Mandrake and Win2k) and one partion for data sharing among these OSes on this disk. As least common denominator I use FAT32 for the exchange partion, where I put my incoming mail on. Emacs offers movemail compilation with a different locking mechanism - lock files. As the mail is put on the msdos partition by procmail only perhaps this is save enough - I will try that. My hesitation comes from the Emacs FAQ that says that it is a bad idea to use a different locking strategy than the OS typically does. > but I doubt it would be carried forward in FreeBSD -HEAD, > which I have to say I'm not going to touch right now. Uhm, different topic. When it became apparent to me that movemail was not working as expected I thought "hm, let's have a look how msdos fs is bolted into the kernel" and I strolled around various places in /usr/src. After a while I gave up, I simply had no idea how all those fs work together. Worse is that I see no way to aquire such knowledge then to put a lot of time into reading driver code and experimenting. I suppose that the book from McKusick/Leffler/.. is too old to get a basic grip on what's going on - or? It would be interesting to start a kernel documentation project, but I fear I lack experience, havenot enough time and that it will be hopelessly outdated. Thanks for the time you spent on this! Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Nov 21 2:33: 5 2000 Delivered-To: freebsd-fs@freebsd.org Received: from nil.science-factory.com (Sciencefactory-atm1-181.piro.net [195.135.137.205]) by hub.freebsd.org (Postfix) with ESMTP id C8C0437B479 for ; Tue, 21 Nov 2000 02:33:03 -0800 (PST) Received: (from mvw@localhost) by nil.science-factory.com (8.11.1/8.11.1) id eALAWSq16643; Tue, 21 Nov 2000 11:32:28 +0100 (CET) (envelope-from marc.vanwoerkom@science-factory.com) Date: Tue, 21 Nov 2000 11:32:28 +0100 (CET) Message-Id: <200011211032.eALAWSq16643@nil.science-factory.com> X-Authentication-Warning: nil.science-factory.com: mvw set sender to marc.vanwoerkom@science-factory.com using -f From: Marc van Woerkom To: bp@butya.kz Cc: marc.vanwoerkom@science-factory.com, freebsd-fs@freebsd.org In-reply-to: (message from Boris Popov on Tue, 21 Nov 2000 08:31:46 +0600 (ALMT)) Subject: Re: MSDOS FS and flock? References: Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Yes, msdosfs doesn't implement advisory locks. Attached you'll > find a diff against recent -current (but should work on -stable > too) which adds necessary VOP to msdosfs. Thank you very much for that patch. I will give it a try. As it does not look esoteric, is there a reason why it is not in -CURRENT? Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Nov 21 10:55:21 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 484C737B479 for ; Tue, 21 Nov 2000 10:55:18 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id LAA18386; Tue, 21 Nov 2000 11:53:09 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAAEhaWzJ; Tue Nov 21 11:52:27 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA28358; Tue, 21 Nov 2000 11:54:16 -0700 (MST) From: Terry Lambert Message-Id: <200011211854.LAA28358@usr08.primenet.com> Subject: Re: MSDOS FS and flock? To: marc.vanwoerkom@science-factory.com (Marc van Woerkom) Date: Tue, 21 Nov 2000 18:54:16 +0000 (GMT) Cc: bp@butya.kz, marc.vanwoerkom@science-factory.com, freebsd-fs@FreeBSD.ORG In-Reply-To: <200011211032.eALAWSq16643@nil.science-factory.com> from "Marc van Woerkom" at Nov 21, 2000 11:32:28 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Yes, msdosfs doesn't implement advisory locks. Attached you'll > > find a diff against recent -current (but should work on -stable > > too) which adds necessary VOP to msdosfs. > > Thank you very much for that patch. > I will give it a try. > As it does not look esoteric, is there a reason why it is not > in -CURRENT? It's really the wrong approach going forward, since it means that the work has to be duplicated (with the possibility of error) for each and every VFS that is ever implemented. It's also very hard to implement every little detail for every VFS, since not only is there the possibility of duplication error, there are enough VFS' that keeping all of them synchronized is a big job. This type of thing really falls through the cracks all the time, unless it is implemented in common code. If you get into it in any detail, you'll see that root mounts aren't supported on many VFS types, either, and that there are similar caveats elsewhere (like the special device, named pipe, socket, and FIFO ownership and permissions issues I noted before). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Nov 21 18:13:59 2000 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 4274837B4C5 for ; Tue, 21 Nov 2000 18:13:56 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id DE7A62909F; Wed, 22 Nov 2000 08:13:52 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id D567B28A25; Wed, 22 Nov 2000 08:13:52 +0600 (ALMT) Date: Wed, 22 Nov 2000 08:13:52 +0600 (ALMT) From: Boris Popov To: Terry Lambert Cc: Marc van Woerkom , freebsd-fs@FreeBSD.ORG Subject: Re: MSDOS FS and flock? In-Reply-To: <200011211854.LAA28358@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 21 Nov 2000, Terry Lambert wrote: > > Thank you very much for that patch. > > I will give it a try. > > As it does not look esoteric, is there a reason why it is not > > in -CURRENT? > > It's really the wrong approach going forward, since it means that > the work has to be duplicated (with the possibility of error) for > each and every VFS that is ever implemented. It is not a "little detail", but a normal vnode operation. It is up to filesystem author/maintainer to decide which operations should be implemented and which not. In this particular case there is no code duplication other than wrapper to standard function. Of course, if this patch going to be committed, then vop_stdadvlock() should be introduced. > If you get into it in any detail, you'll see that root mounts > aren't supported on many VFS types, either, and that there are > similar caveats elsewhere (like the special device, named pipe, > socket, and FIFO ownership and permissions issues I noted before). Indeed, but evolution of VFS is not finished :) -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Nov 22 14: 1:54 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id DB39137B4C5 for ; Wed, 22 Nov 2000 14:01:51 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id OAA04004; Wed, 22 Nov 2000 14:59:47 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpdAAAITayHh; Wed Nov 22 14:59:33 2000 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA04375; Wed, 22 Nov 2000 15:01:17 -0700 (MST) From: Terry Lambert Message-Id: <200011222201.PAA04375@usr07.primenet.com> Subject: Re: MSDOS FS and flock? To: bp@butya.kz (Boris Popov) Date: Wed, 22 Nov 2000 22:01:17 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), marc.vanwoerkom@science-factory.com (Marc van Woerkom), freebsd-fs@FreeBSD.ORG In-Reply-To: from "Boris Popov" at Nov 22, 2000 08:13:52 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > As it does not look esoteric, is there a reason why it is not > > > in -CURRENT? > > > > It's really the wrong approach going forward, since it means that > > the work has to be duplicated (with the possibility of error) for > > each and every VFS that is ever implemented. > > It is not a "little detail", but a normal vnode operation. It is > up to filesystem author/maintainer to decide which operations should be > implemented and which not. In this particular case there is no code > duplication other than wrapper to standard function. Of course, if this > patch going to be committed, then vop_stdadvlock() should be introduced. Well, ignoring the fact that "vop_std*" takes the decision out of the authors hands... ;^) I think the only way a vop_stdadvlock() can be introduced is if the lock list moves off of a per VFS addressed list, like that in UFS and in the MSDOSFS patch, The problem is that the only non-opaque method of creating a uniform FS object reference is the vnode. That means the list has to be hung off the vnode, for the code to be centralized. > > If you get into it in any detail, you'll see that root mounts > > aren't supported on many VFS types, either, and that there are > > similar caveats elsewhere (like the special device, named pipe, > > socket, and FIFO ownership and permissions issues I noted before). > > Indeed, but evolution of VFS is not finished :) Ugh. Software does not evolve. It is designed, and it is implemented. Designs _may_ evolve, but only if insufficient thought went into them before they were implemented (otherwise they wouldn't _need_ to evolve). When a design evolves, it should be taken as an object lesson by the original designer that they need to be more methodical and/or precise in all their future work. I view "software evolution" the way many non-US programmers view "software bugs". In many places, people don't call them "bugs", they call them "defects". The term "evolution" ducks responsibility for design, in the same way the term "bugs" ducks resonsibility for defects. People should be forced to take responsibility where they are responsible, instead of blaming "fate", "luck", "bugs", or "evolution". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Nov 22 18: 6:46 2000 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 7A34637B4F9 for ; Wed, 22 Nov 2000 18:06:42 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id 99E14285CC; Thu, 23 Nov 2000 08:06:39 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 8A9C5285C4; Thu, 23 Nov 2000 08:06:39 +0600 (ALMT) Date: Thu, 23 Nov 2000 08:06:39 +0600 (ALMT) From: Boris Popov To: Terry Lambert Cc: freebsd-fs@FreeBSD.ORG Subject: Re: MSDOS FS and flock? In-Reply-To: <200011222201.PAA04375@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 22 Nov 2000, Terry Lambert wrote: > > duplication other than wrapper to standard function. Of course, if this > > patch going to be committed, then vop_stdadvlock() should be introduced. > > Well, ignoring the fact that "vop_std*" takes the decision out > of the authors hands... ;^) No, it doesn't - presence of vop_std* functions doesn't mean that they are included in the default VOPs. And even in the later case, after is free to overload them. > I think the only way a vop_stdadvlock() can be introduced is if > the lock list moves off of a per VFS addressed list, like that > in UFS and in the MSDOSFS patch, The problem is that the only > non-opaque method of creating a uniform FS object reference is > the vnode. That means the list has to be hung off the vnode, > for the code to be centralized. Yes, sounds reasonable. > > Indeed, but evolution of VFS is not finished :) > > Ugh. Software does not evolve. It is designed, and it is "Ugh" - don't take things too literally. I'm pretty aware of the stages included in the software development processes, but sometimes choose incorrect terms in the non-native language :) -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Nov 22 23:29:39 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mta5-rme.xtra.co.nz (mta5-rme.xtra.co.nz [203.96.92.17]) by hub.freebsd.org (Postfix) with ESMTP id F044E37B479; Wed, 22 Nov 2000 23:27:47 -0800 (PST) Received: from themail.com ([210.54.197.59]) by mta5-rme.xtra.co.nz with SMTP id <20001123072744.OAIP60565.mta5-rme.xtra.co.nz@themail.com>; Thu, 23 Nov 2000 20:27:44 +1300 From: "turehu" To: Subject: Accept credit cards on-line THE EASY WAY! Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 23 Nov 2000 08:24:45 +1300 Content-Transfer-Encoding: 8bit Message-Id: <20001123072744.OAIP60565.mta5-rme.xtra.co.nz@themail.com> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org No set up fees No monthly interest No minimum transaction fees The only charge is a small percentage of the cost of the transaction. You can not lose money! You only pay fees if you sell your product. Get in the act and launch your online bussiness which will work for you 24hrs a day, seven days a week and it is worldwide. Want to find out more? Go to: http://www.cyberturf.com/creditcard If this Email has reached you by mistake, we apologize. To remove your Email from the mailing list please send: jennifer@nottern.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Nov 23 5: 2:13 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail2.netvision.com.br (nv37.netvision.com.br [200.215.94.37]) by hub.freebsd.org (Postfix) with ESMTP id 9BC5137B479 for ; Thu, 23 Nov 2000 05:02:06 -0800 (PST) Received: from nv12.netvision.com.br (nv12.netvision.com.br [200.247.217.134]) by mail2.netvision.com.br (Postfix) with SMTP id AC19A1752 for ; Thu, 23 Nov 2000 11:01:34 -0200 (BST) From: =?iso-8859-1?q?Andr=E9=20Luiz=20dos=20Santos?= Reply-To: andre@netvision.com.br Date: Thu, 23 Nov 2000 11:02:32 +0000 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" To: freebsd-fs@FreeBSD.ORG Subject: LFS MIME-Version: 1.0 Message-Id: <00112311023200.03305@nv12.netvision.com.br> Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi... Is there anybody working on porting LFS to freebsd? Have anybody here ha= d=20 problems with it? Thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Nov 23 17:46:40 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 9FD1437B4C5 for ; Thu, 23 Nov 2000 17:46:37 -0800 (PST) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA14399; Thu, 23 Nov 2000 18:45:32 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAAbyaOgC; Thu Nov 23 18:45:26 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA06289; Thu, 23 Nov 2000 18:46:27 -0700 (MST) From: Terry Lambert Message-Id: <200011240146.SAA06289@usr06.primenet.com> Subject: Re: MSDOS FS and flock? To: bp@butya.kz (Boris Popov) Date: Fri, 24 Nov 2000 01:46:27 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), freebsd-fs@FreeBSD.ORG In-Reply-To: from "Boris Popov" at Nov 23, 2000 08:06:39 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Well, ignoring the fact that "vop_std*" takes the decision out > > of the authors hands... ;^) > > No, it doesn't - presence of vop_std* functions doesn't mean that > they are included in the default VOPs. And even in the later case, after > is free to overload them. You are right, that I was talking about the defaults. I made the assumption that, if a standard mechanism was provided, that it would quickly find itself in the defaults. It's a chicken-and-egg problem: to get rid of them, you have to know they are there. It's actually worse than that, though. If I have NFS, I want to assert the lock locally, so that I don't generate traffic: I am now back in the business of reimplementing the default VOP in the NFS VOP, so that I can have both the NFS behaviour and the local assertion, simultaneously. You could argue that the extra NFS traffic was the price of using NFS. But the issue is more complicated than that, when I introduce a stacking layer. If I have a stacking layer that adds two files together, then I may have a lock that crosses the boundary. If I have a stacking layer that is exposed in the filesystem namespace, and the layer stacked below it is also exposed, then I want the upper layer to honor locks that are asserted against the lower layer, independent of the upper layer: these lock lists are on different vnodes. I can make this work for the lower layer honoring the upper, by having the upper layer assert locks on the lower before granting them on the upper. Going the other way is a matter of holding the lower layer vnode over the assertion, so that a lower layer assertion can't progress. All of these things say that the system call wants to operate on a vnode itself, and call VOP_ADVLOCK in the underlying code -- not to make the assertion, but to permit the assertion to propagate, if necessary, and to permit the lower layer to veto the completion of the operation in the upper layer, if the lower layer can not/will not permit the propagation and/or lower level assertion. > > Ugh. Software does not evolve. It is designed, and it is > > "Ugh" - don't take things too literally. I'm pretty aware of the > stages included in the software development processes, but sometimes > choose incorrect terms in the non-native language :) Sorry; I have a hard time distinguishing between that, and a religious zealot who has bought into "The Cathedral and the Bazaar". 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message