From owner-freebsd-hackers Fri Oct 19 6:14:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mongrel.pacific.net.au (mongrel.pacific.net.au [61.8.0.107]) by hub.freebsd.org (Postfix) with ESMTP id 3F84B37B407 for ; Fri, 19 Oct 2001 06:14:28 -0700 (PDT) Received: from dungeon.home (ppp223.dyn249.pacific.net.au [203.143.249.223]) by mongrel.pacific.net.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id XAA21776; Fri, 19 Oct 2001 23:12:30 +1000 X-Authentication-Warning: mongrel.pacific.net.au: Host ppp223.dyn249.pacific.net.au [203.143.249.223] claimed to be dungeon.home Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.3/8.11.1) with ESMTP id f9JDFHS20600; Fri, 19 Oct 2001 23:15:17 +1000 (EST) (envelope-from mckay) Message-Id: <200110191315.f9JDFHS20600@dungeon.home> To: Matt Dillon Cc: hackers@freebsd.org, mckay@thehub.com.au Subject: vmiodirenable vs isofs, some proof Date: Fri, 19 Oct 2001 23:15:17 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG About a month ago I suggested that vfs.vmiodirenable=1 and the cd9660 file system interract badly. I have not got absolute proof, but I think fairly good evidence of a causal link. At work I have an Athlon 1.4GHz with 512MB ram, IDE disk, IDE burner running FreeBSD 4.4 (no special options). For the last few days, I have had vfs.vmiodirenable=1 without any non-CD related strangeness. I mounted a CD full of mp3s (about 600MB). I copied the contents to the IDE disk (using tar piped to tar). Other programs were active (linux opera, xmms, xterms, probably others), but I wasn't thrashing the box. Shortly after copying the files, I noticed that many files had the wrong contents. In particular, in most directories, the n'th file had the contents of the n'th file of the first directory. I verified that the mounted CD was in this peculiar state. Files read from the CD had the wrong contents. I copied the files several more times, and the particular file substitutions remained stable (ie the same files had the same wrong contents). I set vfs.vmiodirenable=0 and copied again. Exactly the same incorrect files. In other words, the corruption, whatever it is, was not magically removed by disabling vmiodirenable while the cache remained. I unmounted and remounted the CD. A copy operation was flawless at this point (vmiodirenable still off). I enabled vmiodirenable and the next copy was corrupt in the same manner (cross linked files), but the set of cross links was different than before. (Dang, I can't remember if I did another unmount/remount cycle before this copy. Oh well.) At this point, I noticed that the cross links were actual hard links in my HD copies. (I should have noticed how fast they were copying, I suppose). Using "ls -li" on the cdrom showed low inode numbers instead of the high numbers you would expect, and most directories contained the same set of low inode numbers. (Again I have erred. I've left my saved directory listings at work. The "bad" inums were < 1000 while normal inums are > 50000, at least on this CD.) Is this enough for you to form a theory? Any more experiments you think would be worthwhile? Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message