Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Hi all! We have been experiencing an issue on site where threads have been missing the latest postings. The platform host Vanilla are working on this issue. A workaround that has been used by some is to navigate back from 1 to 10+ pages to re-sync the thread and this will then show the latest posts. Thanks, Mike.
Hi there,
There is an issue with role permissions that is being worked on at the moment.
If you are having trouble with access or permissions on regional forums please post here to get access: https://www.boards.ie/discussion/2058365403/you-do-not-have-permission-for-that#latest

Scsi array - Capacity misreported

  • 02-05-2006 2:59pm
    #1
    ronanp
    Closed Accounts Posts: 365 ✭✭


    Howye,

    Sorry about this but been searching for answers for a few days and getting nowhere, thought some decent sort might be able to help!

    We've a VTrak M300p storage unit here which has 8 400gb disks in a Raid 5 array. A logical drive was set up with a capacity of 2.54TB and from the console on the VTrak everything seems to be functional.

    Its attached to another vtrak unit (different model, scsi id=2) which is connecting to a server running Redhat 9. (It was like that when I got here!). Now before the grub loader comes up the scsi bus is scanned and reports all the scsi devices and their capacities correctly (the new vtrak is scsi id 3). However the redhat installation shows the array to have a capacity of 539.3gb as shown by the relevant section of fdisk -l output:
    Disk /dev/sdc: 1294.9 GB, 1294999552000 bytes
    255 heads, 63 sectors/track, 157441 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot Start End Blocks Id System
    /dev/sdc1 * 1 157441 1264644801 83 Linux

    Note: sector size is 1024 (not 512)

    Disk /dev/sdd: 593.9 GB, 593975443456 bytes
    255 heads, 63 sectors/track, 36106 cylinders
    Units = cylinders of 16065 * 1024 = 16450560 bytes

    Disk /dev/sdd doesn't contain a valid partition table

    This size was reported prior to and after partitioning /dev/sdd and making a filesystem on it.

    Output of /proc/scsi/scsi is as follows:
    [root@***** home]# cat /proc/scsi/scsi
    Attached devices:
    Host: scsi0 Channel: 00 Id: 00 Lun: 00
    Vendor: FUJITSU Model: MAB3091SC Rev: 0109
    Type: Direct-Access ANSI SCSI revision: 02
    Host: scsi0 Channel: 00 Id: 01 Lun: 00
    Vendor: FUJITSU Model: MAB3091SC Rev: 0109
    Type: Direct-Access ANSI SCSI revision: 02
    Host: scsi1 Channel: 00 Id: 02 Lun: 00
    Vendor: Promise Model: 8 Disk RAID5 Rev: 1.10
    Type: Direct-Access ANSI SCSI revision: 03
    Host: scsi1 Channel: 00 Id: 03 Lun: 00
    Vendor: Promise Model: VTrak M300p Rev: 2200
    Type: Direct-Access ANSI SCSI revision: 04

    Boot logs show:
    May 2 12:01:59 x kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
    May 2 12:01:59 x kernel: <Adaptec aic7899 Ultra160 SCSI adapter>
    May 2 12:01:59 x kernel: aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
    May 2 12:01:59 x kernel:
    May 2 12:01:59 x kernel: scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
    May 2 12:01:59 x kernel: <Adaptec aic7899 Ultra160 SCSI adapter>
    May 2 12:02:00 x kernel: aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
    May 2 12:02:00 x kernel:
    May 2 12:02:00 x kernel: blk: queue dfce8014, I/O limit 4095Mb (mask 0xffffffff)
    May 2 12:02:00 x kernel: Vendor: FUJITSU Model: MAB3091SC Rev: 0109
    May 2 12:02:00 x kernel: Type: Direct-Access ANSI SCSI revision: 02
    May 2 12:02:00 x kernel: blk: queue dfce8214, I/O limit 4095Mb (mask 0xffffffff)
    May 2 12:02:00 x kernel: Vendor: FUJITSU Model: MAB3091SC Rev: 0109
    May 2 12:02:00 x kernel: Type: Direct-Access ANSI SCSI revision: 02
    May 2 12:02:00 x kernel: blk: queue dfce8614, I/O limit 4095Mb (mask 0xffffffff)
    May 2 12:02:00 x kernel: scsi0:A:0:0: Tagged Queuing enabled. Depth 253
    May 2 12:02:00 x kernel: scsi0:A:1:0: Tagged Queuing enabled. Depth 253
    May 2 12:02:00 x kernel: Vendor: Promise Model: 8 Disk RAID5 Rev: 1.10
    May 2 12:02:00 x kernel: Type: Direct-Access ANSI SCSI revision: 03
    May 2 12:02:00 x kernel: blk: queue dfce8a14, I/O limit 4095Mb (mask 0xffffffff)
    May 2 12:02:00 x kernel: Vendor: Promise Model: VTrak M300p Rev: 2200
    May 2 12:02:00 x kernel: Type: Direct-Access ANSI SCSI revision: 04
    May 2 12:02:00 x kernel: blk: queue dfce8c14, I/O limit 4095Mb (mask 0xffffffff)
    May 2 12:02:00 x kernel: scsi1:A:2:0: Tagged Queuing enabled. Depth 253
    May 2 12:02:00 x kernel: scsi1:A:3:0: Tagged Queuing enabled. Depth 253
    May 2 12:02:00 x kernel: Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
    May 2 12:02:00 x kernel: Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
    May 2 12:02:00 x kernel: Attached scsi disk sdc at scsi1, channel 0, id 2, lun 0
    May 2 12:02:00 x kernel: Attached scsi disk sdd at scsi1, channel 0, id 3, lun 0
    May 2 12:02:00 x kernel: (scsi0:A:0): 40.000MB/s transfers (20.000MHz, offset 31, 16bit)
    May 2 12:02:00 x kernel: SCSI device sda: 17824700 512-byte hdwr sectors (9126 MB)
    May 2 12:02:00 x kernel: Partition check:
    May 2 12:02:00 x kernel: sda: sda1 sda2 sda3 sda4 < sda5 >
    May 2 12:02:00 x kernel: (scsi0:A:1): 40.000MB/s transfers (20.000MHz, offset 31, 16bit)
    May 2 12:02:00 x kernel: SCSI device sdb: 17824700 512-byte hdwr sectors (9126 MB)
    May 2 12:02:00 x kernel: sdb: sdb1
    May 2 12:02:00 x kernel: (scsi1:A:2): 160.000MB/s transfers (80.000MHz DT, offset 62, 16bit)
    May 2 12:02:00 x kernel: SCSI device sdc: 2529296000 512-byte hdwr sectors (1295000 MB)
    May 2 12:02:00 x kernel: sdc: sdc1
    May 2 12:02:00 x kernel: (scsi1:A:3): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
    May 2 12:02:00 x kernel: SCSI device sdd: 2727537792 1024-byte hdwr sectors (593975 MB)
    May 2 12:02:01 x kernel: sdd: unknown partition table

    I realise the partition table error stands out a mile, but the same error was reported prior to and after partitioning the drive.

    Thanks for any help, greatly appreciated!
    Ronan


Comments

  • #2
    leeroybrown
    Closed Accounts Posts: 7,563 ✭✭✭leeroybrown


    Suggestions:

    (1) Is the firmware up to date on it? I've seen firmware bugs on disk trays causing wierd problems before.

    (2) Is the AIC7XXX driver in that Redhat 9 kernel capible of handling arrays >2Tb? That 2Gb+ array requires a change to 1024-byte sectors to keep the sector count as a 10 digit value.


  • #3
    ronanp
    Closed Accounts Posts: 365 ✭✭ronanp


    The firmware hasn't been updated, no, but i've been unable to find other examples of the same problem.

    The driver/kernel issue is one that i've been thinking of alright, as the scsi bios sees the capacity correctly prior to grub booting the kernel. My issue though is that another vtrak array of 1.2 tb on the same chain, which is at 95%, cannot risk being taken offline for any length of time longer than a minute or two.

    The new array has already been created with 1024 byte sectors as it is over 2tb.


  • #4
    leeroybrown
    Closed Accounts Posts: 7,563 ✭✭✭leeroybrown


    ronanp wrote:
    The new array has already been created with 1024 byte sectors as it is over 2tb.
    That was my point. The Redhat 9 driver may not cope all that well with this change.

    If you can't afford any unnecessary downtime and don't have a second SCSI adapter elsewhere to test the second unit then I would suggest finding some changelogs for the AIC7XXX driver and going through them from the version you are running to the latest version. This should give you a very strong indication if you need to try a newer driver.


  • #5
    ronanp
    Closed Accounts Posts: 365 ✭✭ronanp


    leeroybrown wrote:
    That was my point. The Redhat 9 driver may not cope all that well with this change.

    If you can't afford any unnecessary downtime and don't have a second SCSI adapter elsewhere to test the second unit then I would suggest finding some changelogs for the AIC7XXX driver and going through them from the version you are running to the latest version. This should give you a very strong indication if you need to try a newer driver.


    Cheers, That's exactly what i'll do!


  • #6
    leeroybrown
    Closed Accounts Posts: 7,563 ✭✭✭leeroybrown


    Did you have any luck sorting this out?


  • Advertisement
  • #7
    ronanp
    Closed Accounts Posts: 365 ✭✭ronanp


    Not yet, but about to boot into a 2.6 kernel instead which should hopefully do the job.


  • #8
    ronanp
    Closed Accounts Posts: 365 ✭✭ronanp


    After much messing about this is finally sorted. Just in case anyone runs into a similar problem and stumbled onto this page, here's what happened:

    After installing the 2.6 kernel, fdisk was correctly reporting the size of the drive. However, fdisk can't handle partitions over 2tb, so when trying to partition the drive with fdisk I ended up again with a 0.54tb partition.

    One attempted solution was to just make a filesystem on the drive directly without partitioning. It did sound like a bad idea straight off but i'd read a few good reports. It initially seemed to work too, and df showed the correct size, e2fsck reported no errors, but during the data transfer there were a good few I/O errors and it was thought safest to abandon that idea and start again.

    GNU Parted is known to handle 2tb+ partitions better than fdisk but is also known not to work on 1024 byte sectors, so the array was rebuilt (yet again!) with a 512 byte sector size. Then I used parted to create a gpt disklabel on the array and to make a partition of 2663383mb (2.54*1024*1024), ran mkfs.ext3 to create a filesystem on the partition and everything came up smelling of roses.

    Summary: fdisk = ****e, parted = good.


Advertisement