[Andrea's explanation snipped]
> >When I shut down my box just now, as it was unmounting filesystems, I
> >got this message (copied by hand and retyped but checked):
> >
> >set_blocksize: b_count 3, dev ide0(3,1), block 1686626
> >set_blocksize: b_count 1, dev ide0(3,1), block 1686628
> >set_blocksize: b_count 1, dev ide0(3,1), block 1686629
> >set_blocksize: b_count 1, dev ide0(3,1), block 1686627
> >set_blocksize: b_count 1, dev ide0(3,1), block 181674
>
> Could you tell me which filesystem are you using on /dev/hda1?
It's vfat.
> If you was doing read-I/O on a blockdevice while mounting an fs the above
> is harmless.
No, there's no mounting going on at that time. Just unmounting.
> If it's instead a filesystem that is not relasing all buffers before
> calling set_blocksize, it would be better to fix the fs properly if
> possible. It could harmless also for a filesystem, but if the filesystem
> will continue to use the old-sized buffers for some time, it can lose
> coherency with the rest of the buffer cache and it can read obsolete data
> potentially causing fs corruption. The printk I added there wants to catch
> exactly this kind of issues that was silenty ignored by the old 2.2.13
> set_blocksize.
Okay, so it looks like a bug in fat/vfat? Wouldn't surprise me ;-) And
since it happens at umount time, the case where "the filesystem
continues to use old-sized buffers for some time" shouldn't apply-- the
filesystem gets disused right away. So I'm probably not in any real
trouble. (I do have backups, anyway.)
[patch snipped]
All right, I shall apply this patch and report any new information.
Thanks very much!
--Nate Eldredge neldredge@hmc.edu
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/