On Wed, Oct 18, 2006 at 08:44:39AM +1000, Norberto Meijome wrote: > On Tue, 17 Oct 2006 17:33:50 -0500 > Brooks Davis <[EMAIL PROTECTED]> wrote: > > > > Gotcha - i thought as much... i hoped a dump -0 would save enough info > > > though. I just needed to have /tmp back in place asap.... > > > > > > i'll keep the files around for a week or so in case something comes up. > > > > Good thought, but anything short of "dd if=/dev/<tmpdevices> > > of=/path/to/some/location" probably won't preserve the corrupt bits. > > Think of dump as a version of tar that also knows how to read file > > systems directly. It only preserves files and their contents not the > > actual file system bits on the disk > > Yes, I realise that now, it was late and I wasn't thinking too straight > obviously. > > BTW, the mount in 6.1-RELEASE CD had no issue at all mounting the filesystem.. > dump I used was 6.1-RELEASE too . would have been user land app related, or > actual UFS kernel code that made the difference?
That's somewhat distrubing. That sounds like a change to the UFS code somehow made things more fragile, though it could be an access pattern issue of some sort. -- Brooks
pgpFAkZ9X54D0.pgp
Description: PGP signature
