Date: Tue, 25 Jul 95 14:53:09 MDT From: terry@cs.weber.edu (Terry Lambert) To: dfr@render.com (Doug Rabson) Cc: current@freefall.cdrom.com, joerg_wunsch@uriah.heep.sax.de Subject: Re: Interesting NFS problem with -current Message-ID: <9507252053.AA17127@cs.weber.edu> In-Reply-To: <Pine.BSF.3.91.950725103308.230C-100000@minnow.render.com> from "Doug Rabson" at Jul 25, 95 10:36:42 am
next in thread | previous in thread | raw e-mail | index | archive | help
> The mount-time could be added to the filehandle (someone suggested this > to me as a possible readdir cookie verifier for cd9660). That would > certainly detect disk-changes but it would also invalidate filehandles > for the same disk which was mounted twice. We're worried about media changes, right? Ones that don't involve remounting the same media? > Hmm. No this wouldn't work because if the server rebooted, then all the > clients would lose. What we need is a unique signature for the disk. > What about an MD5 checksum for the first few hundred blocks? There's supposed to be a unique disk ID generated from the manufacturer and a manufacturer ID for that. In practice, this almost never happens. Ask Jordan why. 8-). I think the MD5 checksum is probably the best mechanism. I'd use the root directory blocks, however, which means generating it at mount time. There's no guarantee that there will even be data other than a potentially non-unique header at the front of the disk. Linux actually doesn't flush the buffer cache for unmounted CDROMs(!) unless they detect a real media change, as opposed to a media out/in without a disk change. Because the cdrom instance is seperate for each cdrom when using a changer, this give Linux a big advantage on changers. Something to think about if you're going to be in the code anyway... Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9507252053.AA17127>