[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20420.1201625624@turing-police.cc.vt.edu>
Date: Tue, 29 Jan 2008 11:53:44 -0500
From: Valdis.Kletnieks@...edu
To: Andrew Morton <akpm@...ux-foundation.org>,
David Howells <dhowells@...hat.com>
Cc: linux-kernel@...r.kernel.org
Subject: 2.6.24-rc6-mm1 - iget-stop-isofs-from-using-read_inode-fix-2.patch
Sorry for the late notice - I hit the original issue with this code,
and I tested the *first* patch, which addressed my immediate problem, but
didn't test the subsequent flurry of "better" patches due to time issues
here.
I back up my laptop by doing one or more 'dump' commands into a $STAGE directory,
and then doing a 'growisofs' onto a DVD. And of course, I eventually needed
to restore something that got damaged by some misbehaving userspace, so I break
out the disk, which had 8 dump images for smaller filesystems on it. Imagine
my surprise when the disk was unreadable - so I went bisecting and eventually
found it first in the -rc6-mm1 tree.
Under 2.6.4-rc6-mm1 quilted up to iget-stop-isofs-from-using-read_inode.patch,
it's able to see all 8 dump images. When I quilt push the very next one
(iget-stop-isofs-from-using-read_inode-fix-2.patch), all hell breaks loose:
[root@...ing-police ~]# mount -t iso9660 /dev/cdrom /mnt/cdrom
[root@...ing-police ~]# ls -la /mnt/cdrom
total 0
[root@...ing-police ~]# umount /mnt/cdrom
It claims to mount correctly - but ls can't find anything.
*not even . and .. - how weird is that?*
Looking at the code, I don't see why inode-fix-2 breaks it, nor do I see
why inode-fix-2-update or inode-fix-2-update-fix don't re-fix it...
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists