Date: Fri, 19 Oct 2001 23:15:17 +1000 From: Stephen McKay <mckay@thehub.com.au> To: Matt Dillon <dillon@earth.backplane.com> Cc: hackers@freebsd.org, mckay@thehub.com.au Subject: vmiodirenable vs isofs, some proof Message-ID: <200110191315.f9JDFHS20600@dungeon.home>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110191315.f9JDFHS20600>