Linux see LUN/disk bigger

[skt_skt]

Red Hat Enterprise Linux AS release 4 (Nahant Update 7)

2.6.9-78.0.24.0.1.ELsmp #1 SMP Tue Jun 2 16:02:43 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

Array EMC Clariion CX500

LUN size is not matching with the size showing in the linux
kernel level ( This is happening across all the versions of RHEL AS linux).

ALU# Raid Grp# Raid Type Size/MB's Host(fdisk) Host(INQ)KB
25 RG0 Raid 5 517896 543.0 GB 530325952

As you can see the array/inq reports the "right" size, but the fdisk report a higer size.It is true for all the LUNs we checked.

HERE IS why asking the above question. I had the follwoing error "/dev/emcpowerx: read failed after 0 of 4096 at 42949607424: Input/output error" and it was explained as BELOW.

sometimes Linux kernel doesn't pick up a correct size of the detected devices, which apparently was the case here:

---
ONLINE SCAN:

Jan 20 12:54:25 tneld67n kernel: qla2400 0000:10:00.0: Scheduling rescan for new luns...
Jan 20 12:54:25 tneld67n kernel: qla2400 0000:07:00.0: Scheduling rescan for new luns...
Jan 20 12:54:56 tneld67n kernel: qla2400 0000:07:00.0: Scheduling rescan for new luns...
Jan 20 12:54:56 tneld67n kernel: qla2400 0000:10:00.0: Scheduling rescan for new luns...
Jan 20 12:55:50 tneld67n kernel: SCSI device sdbt: 83886080 512-byte hdwr sectors (42950 MB)
Jan 20 12:55:50 tneld67n kernel: SCSI device sdbt: drive cache: write through
Jan 20 12:55:50 tneld67n kernel: sdbt: unknown partition table
Jan 20 12:55:50 tneld67n kernel: SCSI device sdbr: 83886080 512-byte hdwr sectors (42950 MB)
Jan 20 12:55:50 tneld67n kernel: SCSI device sdbr: drive cache: write through
Jan 20 12:55:50 tneld67n kernel: sdbr: unknown partition table
Jan 20 12:55:50 tneld67n kernel: emcpowerx: unknown partition table

REAL SIZE OF THE LUN (navicli getall):

LOGICAL UNIT NUMBER 467
Name LUN 467
UID: 60:06:01:60:68:CF:1A:00:20:BE:04:D6:EC:05:DF:11
(...)
LUN Capacity(Megabytes): 40960
LUN Capacity(Blocks): 83886080
---

So it looks like Linux 'thought' that the LUN is 2G bigger than it was in reality. There will be no problem unless OS is actually trying to write something after the physical boundary of the device, so it may happen that the host is running for weeks without issues. And the reboot fixed the issue.

Question how LINUX/fdisk calculates the size.

[Matti_Kurkela · Accepted solution]

This is another consequence of confusion between 1000 vs 1024-based unit prefixes when measuring computer storage.

With larger units, this can lead to significant display deviations:

http://en.wikipedia.org/wiki/Binary_prefix#Deviation_between_binary_and_decimal_interpretations

If "inq" uses 1024-based prefixes, the LUN size would be 543 053 774 848 bytes.

The fdisk interprets that value using 1000-based unit prefixes, resulting in 543 GB.

You can verify this by running "fdisk -l " on your LUN and reading the first non-blank line of the output. It should be something like:

Disk /dev/sda: 160.0 GB, 160041885696 bytes

To eliminate this confusion, a new set of unit prefixes was standardized in 2005 (see the wikipedia URL above).

According to those standards, the inq tool should list the size as 530325952 KiB, not 530325952 KB.

It might be useful if Linux fdisk would show the size of the disk in both ways. In your case, the LUN size might be indicated as 543.0 GB / 505.7 GiB.

-------

> Jan 20 12:55:50 tneld67n kernel: SCSI device sdbt: 83886080 512-byte hdwr sectors (42950 MB)
> LUN Capacity(Megabytes): 40960
> LUN Capacity(Blocks): 83886080

The size in sectors a.k.a. blocks is exactly the same, so the difference in megabyte values is a display problem only.

83886080 sectors * 512 bytes/sector =
42949672960 bytes.

In 1000-based units, this is:
42949672960 / 1000 = 42949672 KB
42949672960 / 1000^2 = 42950 MB (rounded up)
42949672960 / 1000^3 = 42.9 GB

In 1024-based units, this is:
42949672960 / 1024 = 41943040 KiB
42949672960 / 1024^2 = 40960 MeB
42949672960 / 1024^3 = 40.0 GiB (exact)

> read failed after 0 of 4096 at 42949607424

The read operation would have ended at byte location 42949607424 + 4096 = 42949611520.

end of disk: 42949672960
end of read operation: 42949611520
----------------------------------
61440

The difference is positive, so the access should have fit nicely within the LUN!

Looks like the explanation given to you was... hasty.

MK

[skt_skt]

that was very good explanation. What is the theory of adding 4096 to the byte location.

[Matti_Kurkela]

The error message was: "/dev/emcpowerx: read failed after 0 of 4096 at 42949607424: Input/output error"

My interpretation: the program is trying to read a 4096 byte block ("... of 4096") starting from byte 42949607424. The read operation was completely unsuccessful: no part of data was returned ("0 of 4096").

The start location of the read operation is obviously within the LUN size, but I wanted to explicitly prove that the end point of the read operation is also within the LUN size.

If the block had been partly outside the LUN size, that might have explained the error (maybe a sanity check stops any attempts to access beyond end of device?) but this does not seem to be the case.

MK