troubleshooting file corruption problem
Hi, I'm running kernel 2.6.8-15, lvm2 v2.01.04-5 and acl v2.2.23-1 on a Sunblade 100. In a few months we have experienced twice of file corruption on an ext3 filesystem created ontop of lvm2 logical volume. The symptom is that the filesystem is remounted as read-only (this is due to the option "errors=remount-ro" in /etc/fstab). The only relevant errors in the log files are: kernel: init_special_inode: bogus i_mode (3016) kernel: init_special_inode: bogus i_mode (3125) kernel: init_special_inode: bogus i_mode (3144) kernel: init_special_inode: bogus i_mode (3231) kernel: init_special_inode: bogus i_mode (3423) kernel: init_special_inode: bogus i_mode (3452) I've run smartmontools to check the disks but no errors are found. I've run "fsck -c" to look up bad blocks but nothing is found. What else can I do to troubleshoot the problem? Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: External SCSI disks with SS20
Hi. Thanks for your answer. On Wednesday 05 October 2005 20:07, Michael-John Turner wrote: > On Tue, Oct 04, 2005 at 09:59:47PM +0200, Hartwig Atrops wrote: > > Regarding Solaris: In my opinion the default boot disk for Solaris is > > SCSI ID 3. I could not check today, as far as I remember I can plug an > > additional SCSI disk with ID 0 to a Solaris machine (Ultra 2) without > > problems. With Linux, this doesn't work. > > You're actually referring to two separate issues. By default, OpenBoot > boots from SCSI ID 3 (you can change this quite easily). Hmm. I know that I can change the OpenBoot setting. But I don't like this idea. "Here comes a new opsys for that machine - to make it work propperly, we are going to change the defaults" - grrr. > Unlike Linux (unless you use something like udev), Solaris refers to SCSI > disks by their location on the bus, eg c0t0d0s1 for controller 0, target 0, > disk 0, slice 1. By default, the Linux kernel names SCSI disks sda, sdb, > etc based on the order it finds them (typically in the order of their SCSI > IDs). In the case where you add another disk with a lower SCSI ID than your > existing disk(s), the existing disk(s) will all "shift down" (sda will > becoming sdb, etc). If you use udev to manage your devices, Linux will do > something similar to Solaris. > > Hope that makes sense :) That clarifies some things. About udev: Kernel 2.6, right? On my SS20 I am still running Woody, kernel 2.4.x. To compile a 2.6 kernel I need Sarge ( because of the gcc version ), right? Does Sarge run on my SS20 - no idea. Does kernel 2.6 run on my SS20 - no idea. Did not go into that yet. But this might be a new thread ... Regards, Hartwig -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: External SCSI disks with SS20
On Tue, Oct 04, 2005 at 09:59:47PM +0200, Hartwig Atrops wrote: > Regarding Solaris: In my opinion the default boot disk for Solaris is > SCSI ID 3. I could not check today, as far as I remember I can plug an > additional SCSI disk with ID 0 to a Solaris machine (Ultra 2) without > problems. With Linux, this doesn't work. You're actually referring to two separate issues. By default, OpenBoot boots from SCSI ID 3 (you can change this quite easily). Unlike Linux (unless you use something like udev), Solaris refers to SCSI disks by their location on the bus, eg c0t0d0s1 for controller 0, target 0, disk 0, slice 1. By default, the Linux kernel names SCSI disks sda, sdb, etc based on the order it finds them (typically in the order of their SCSI IDs). In the case where you add another disk with a lower SCSI ID than your existing disk(s), the existing disk(s) will all "shift down" (sda will becoming sdb, etc). If you use udev to manage your devices, Linux will do something similar to Solaris. Hope that makes sense :) -mj -- Michael-John Turner | http://weblogs.turner.org.za/mj/ [EMAIL PROTECTED]| Open Source in WC ZA - http://www.clug.org.za/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
