Topic: Hardware raid and external USB drive

[compsos]

Hi
We have an external USB backup drive on a system with a 3ware Hardware Raid.

Personalities : [raid1]
md2 : active raid1 sda2[0]
      38973568 blocks [2/1] [U_]

md1 : active raid1 sda1[0]
      104320 blocks [2/1] [U_]

The system thinks there are file system errors on the external drive. I am not positive but think it is being considered part of the raid.
When an fdisk is done on the ext drive it is OK but when mkfs.ext3 is performed it goes so far then accelerates to the end of the drive. The drive is then not usable on this system. Plug it into another system and all can be done and tested OK.

Thanks

Attempts to remove /dev/sdb1 or 2 from the raid fail, which is true as there is no sdb drive been added.

Is it mdadam trying to manage the drive? If so what can be done to keep the backup disk out of mdadm configuration?

[CharlieBrady]

The system thinks there are file system errors on the external drive.

What do you see which makes you think the system "thinks" that?

The drive is then not usable on this system.

What do you mean by that? What are you trying to do with the drive, and what do you see when you try?

I am not positive but think it is being considered part of the raid.

Unlikely.

Your raid status looks perfectly normal.

[compsos]

Hi Charlie

The external drive is for backup. Connected via USB port. If I fdisk the sdb drive it completes but when I mkfs.ext3 the drive it starts OK but then suddenly speeds up the inode count.

The messagesg file repeats the following

Code: [Select]

Aug 11 15:50:07 server-asdg kernel: Attached scsi disk sdb at scsi4708, channel 0, id 0, lun 0
Aug 11 15:50:33 server-asdg kernel: SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
Aug 11 15:50:33 server-asdg kernel: sdb: assuming drive cache: write through
Aug 11 15:50:33 server-asdg kernel: SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
Aug 11 15:50:33 server-asdg kernel: sdb: assuming drive cache: write through
Aug 11 15:50:33 server-asdg kernel:  sdb: sdb1
Aug 11 15:50:33 server-asdg kernel: Attached scsi disk sdb at scsi4709, channel 0, id 0, lun 0
Aug 11 15:51:45 server-asdg kernel: VFS: Can't find a valid FAT filesystem on dev sdb1.
Aug 11 15:53:07 server-asdg kernel: end_request: I/O error, dev sdb, sector 36963103
Aug 11 15:53:07 server-asdg kernel: Buffer I/O error on device sdb1, logical block 18481520
Aug 11 15:53:07 server-asdg kernel: lost page write due to I/O error on sdb1
Aug 11 15:53:07 server-asdg kernel: end_request: I/O error, dev sdb, sector 36963105
Aug 11 15:53:07 server-asdg kernel: Buffer I/O error on device sdb1, logical block 18481521


On mounting

Code: [Select]

mount /dev/sdb1 /media/usbdisk/
mount: you must specify the filesystem type
[root@server-asdg usbdisk]# mkfs.ext3 /dev/sdb1
mke2fs 1.35 (28-Feb-2004)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
39075840 inodes, 78142160 blocks
3907108 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=79691776
2385 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616

Writing inode tables:   47/2385
done
ext2fs_mkdir: Attempt to read block from filesystem resulted in short read while creating root dir

Usually the count gets to around 300 in normal time.

Code: [Select]

fdisk -l /dev/sdb

Disk /dev/sdb: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       38913   312568641   83  Linux

Take the drives off the system and mount on another and they pass all tests, fdisk, mkfs.ext3 and just work. It is the speed up of the inode count that made me think the comms to the drive are changing. You are right the raid does look OK but if it is not the raid what else disturbs the format?

Thanks for your comments.

[CharlieBrady]

... but if it is not the raid what else disturbs the format?

I/O errors.

[Reinhold]

compsos,

3ware Hardware Raid.

Personalities : [raid1]
md2 : active raid1 sda2[0]

Your 3ware does what hardware raid is supposed to do: Present itself as just 1 single drive to the system ... sda   (sda1 sda2)
...like Charlie said ...nothing there concerning your raid (which repeat: SME doesn't even know about)

Aug 11 15:51:45 server-asdg kernel: VFS: Can't find a valid FAT filesystem on dev sdb1.

Most likely your usb disk internal controller isn't up to the task.
Either it's old and really needs a FAT formatted drive
_or_
your HD is a bit too large (capacity 300GB+?!) for its capabilities...
_or_
...in any case go get yourself another/better usb disk 

Regards
Reinhold

[compsos]

Thanks Reinhold
That is what I figured until I plugged into another system, using the same case and cables etc, and all was as expected. The difference between the systems was the Hardware raid. The test platform was software raid only.

The error in the formatting occurs during the mkfs.ext3 /dev/sdb1 but not on the test platform. Maybe a combination of USB controller and ext Device?
TIA

[CharlieBrady]

Maybe a combination of USB controller and ext Device?

Probably.

[compsos]

Does this explain to my confusion?
It Fdisk the partition OK
Fails to format
but can repair with e2fsck
Now is usable. This is happening on 2 ext HDD

Code: [Select]

e2fsck /dev/sdb1 -y
e2fsck 1.35 (28-Feb-2004)
Superblock has a bad ext3 journal (inode 8).
Clear? yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***
Resize inode not valid.  Recreate? yes
/dev/sdb1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory.  Clear? yes
Pass 2: Checking directory structure
Entry '..' in ??? (17907713) has deleted/unused inode 2.  Clear? yes
Pass 3: Checking directory connectivity
Root inode not allocated.  Allocate? yes
Unconnected directory inode 17907713 (...)
Connect to /lost+found? yes
/lost+found not found.  Create? yes
Pass 4: Checking reference counts
Inode 17907713 ref count is 4, should be 3.  Fix? yes
Pass 5: Checking group summary information
Block bitmap differences:  -(1561--9765)
Fix? yes
Free blocks count wrong for group #0 (23000, counted=31207).
Fix? yes
Free blocks count wrong for group #689 (32254, counted=17918).
Fix? yes
Free blocks count wrong for group #690 (32254, counted=6).
Fix? yes
Free blocks count wrong for group #691 (32254, counted=13).
Fix? yes
Free blocks count wrong for group #692 (32254, counted=6).
Fix? yes
Free blocks count wrong for group #693 (32254, counted=13).
Fix? yes
Free blocks count wrong for group #694 (32254, counted=13).
Fix? yes

Free blocks count wrong for group #695 (32254, counted=6).
Fix? yes

Free blocks count wrong for group #696 (32254, counted=6).
Fix? yes

Free blocks count wrong for group #697 (32254, counted=13).
Fix? yes

Free blocks count wrong for group #698 (32254, counted=32185).
Fix? yes

Free blocks count wrong for group #1093 (32254, counted=17826).
Fix? yes
Free blocks count wrong for group #1094 (32254, counted=0).
Fix? yes
Free blocks count wrong for group #1095 (32254, counted=0).
Fix? yes
Free blocks count wrong for group #1096 (32254, counted=0).
Fix? yes
Free blocks count wrong for group #1097 (32254, counted=0).
Fix? yes
Free blocks count wrong for group #1098 (32254, counted=0).
Fix? yes
Free blocks count wrong for group #1099 (32254, counted=27453).
Fix? yes
Free blocks count wrong (76891356, counted=76446703).
Fix? yes
Free inodes count wrong for group #0 (16372, counted=16373).
Fix? yes
Directories count wrong for group #0 (3, counted=2).
Fix? yes
Free inodes count wrong for group #689 (16384, counted=16380).
Fix? yes
Free inodes count wrong for group #1093 (16384, counted=15041).
Fix? yes
Directories count wrong for group #1093 (0, counted=90).
Fix? yes
Free inodes count wrong for group #1098 (16384, counted=16275).
Fix? yes
Directories count wrong for group #1098 (0, counted=60).
Fix? yes
Free inodes count wrong for group #1099 (16384, counted=16382).
Fix? yes
Directories count wrong for group #1099 (0, counted=2).
Fix? yes
Free inodes count wrong (39075828, counted=39074371).
Fix? yes
/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 1469/39075840 files (1.2% non-contiguous), 1695457/78142160 blocks
[root@server-asdg ~]# e2fsck /dev/sdb1 -y
e2fsck 1.35 (28-Feb-2004)
/dev/sdb1: clean, 1469/39075840 files, 1695457/78142160 blocks