Hello, Just want to double check my facts before I do something wrong here. I discovered a computer trying to read past the end of it's disk. attempt to access beyond end of device sdq: rw=0, want=488022554, limit=488017920 fdisk reports: Disk /dev/sdq: 249.8 GB, 249865175040 bytes 255 heads, 63 sectors/track, 30377 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000d7193 Device Boot Start End Blocks Id System /dev/sdq1 1 30 240943+ 83 Linux /dev/sdq2 31 30378 243770310 8e Linux LVM My assumption is that specifying end=30378 is invalid for a disk that only has 30377 cylinders. Have I got this correct? Another identical computer does have end=30377, so I suspect this one got it right. Also wondering why dmesg reports 488017920 blocks but fdisk reports 240943+243770310 block size (and on good system reports 240943+243762277 blocks) - is there a difference in block sizes here? /dev/sdq2 is LVM, and has three partitions for root, swap, and var. --- Physical volume --- PV Name /dev/sdq2 PV Size 232.48 GB / not usable 966.00 KB Allocatable yes PE Size (KByte) 4096 Total PE 59514 Free PE 50403 Allocated PE 9111 PV UUID 58fU6l-MLlo-h5Ar-n9jx-0poC-axdS-VoAmND How do I recover the LVM partition with minimum disruption? Maybe use of pvresize? Before or after fixing the partition size? How can I check if that part of the disk has a LV allocated on it? Thanks -- Brian May <brian@microcomaustralia.com.au>
Brian May wrote:
Hello,
Just want to double check my facts before I do something wrong here.
I discovered a computer trying to read past the end of it's disk.
attempt to access beyond end of device sdq: rw=0, want=488022554, limit=488017920
This is probably because the partition extends beyond the end of the disk, or the filesystem extends beyond the end of the partition/disk.
My assumption is that specifying end=30378 is invalid for a disk that only has 30377 cylinders. Have I got this correct? Another identical computer does have end=30377, so I suspect this one got it right.
I would completely avoid CHS. My preference also runs to parted beats sfdisk beats fdisk (but note that modern fdisk is implemented on top of libparted). $ parted /dev/sdq unit b print The stuff coming out of the kernel is probably in 512b blocks, cf. /proc/partitions.
/dev/sdq2 is LVM, and has three partitions for root, swap, and var. How do I recover the LVM partition with minimum disruption?
Insert another disk. Make it a PV. Move the LVs to it. Remove the original disk from the VG, make it a new PV that fits on the disk, then add it to the VG and move all the LVs back onto the original disk. Finally, remove the temporary disk.
Maybe use of pvresize? Before or after fixing the partition size?
That would probably be better than my suggestion above. You probably want to do it beforehand -- it will depend on whether LVM metadata is allocated from the end of the partition or at the start. Similar fun is encountered with md arrays.
How can I check if that part of the disk has a LV allocated on it?
lvdisplay and friends should be able to list all extents. The extents will probably be in terms of the LVM extent size and count from the start of the PV, not the start of the disk.
On 13 September 2012 17:53, Trent W. Buck <trentbuck@gmail.com> wrote:
I would completely avoid CHS. My preference also runs to parted beats sfdisk beats fdisk (but note that modern fdisk is implemented on top of libparted).
What units are stored in the partition table?
$ parted /dev/sdq unit b print
~ # parted /dev/sdq unit b print Error: Can't have a partition outside the disk! Whoops. I guess this is confirmation that there was a problem.
Maybe use of pvresize? Before or after fixing the partition size?
That would probably be better than my suggestion above.
Shame pvresize doesn't take number of extents for its resize, that would have been more precise. Anyway: ~ # pvresize --verbose --setphysicalvolumesize 232.47G /dev/sdq2 Using physical volume(s) on command line Archiving volume group "stg8" metadata (seqno 6). /dev/sdq2: Pretending size is 487524925 not 487540620 sectors. Resizing physical volume /dev/sdq2 from 59514 to 59512 extents. Resizing volume "/dev/sdq2" to 487524541 sectors. Updating physical volume "/dev/sdq2" Creating volume group backup "/etc/lvm/backup/stg8" (seqno 7). Physical volume "/dev/sdq2" changed 1 physical volume(s) resized / 0 physical volume(s) not resized Gives me the same number of extents as the good system. How do I update the partition table to end at the correct place? Am guessing this will require deleting the partition and re-adding it with fdisk, or is there a better way? To answer another part of my original email, the following displays the mappings of the extents: ~ # pvdisplay --map --- Physical volume --- PV Name /dev/sdq2 VG Name stg8 PV Size 232.47 GB / not usable 1.09 MB Allocatable yes PE Size (KByte) 4096 Total PE 59512 Free PE 50401 Allocated PE 9111 PV UUID 58fU6l-MLlo-h5Ar-n9jx-0poC-axdS-VoAmND --- Physical Segments --- Physical extent 0 to 1775: Logical volume /dev/stg8/swap Logical extents 0 to 1775 Physical extent 1776 to 2886: Logical volume /dev/stg8/var Logical extents 0 to 1110 Physical extent 2887 to 5270: Logical volume /dev/stg8/root Logical extents 0 to 2383 Physical extent 5271 to 6550: Logical volume /dev/stg8/var Logical extents 1111 to 2390 Physical extent 6551 to 9110: Logical volume /dev/stg8/root Logical extents 2384 to 4943 Physical extent 9111 to 59511: FREE Am a bit confused how this error occurred in the first place apparently was a standard Centos 5.x install. So maybe a bug in the installer? -- Brian May <brian@microcomaustralia.com.au>
On 14 September 2012 13:51, Brian May <brian@microcomaustralia.com.au> wrote:
Am a bit confused how this error occurred in the first place apparently was a standard Centos 5.x install. So maybe a bug in the installer?
Small typo - s/Centos 5.x/Debian Lenny/ - oops. -- Brian May <brian@microcomaustralia.com.au>
Brian May wrote:
On 13 September 2012 17:53, Trent W. Buck <trentbuck@gmail.com> wrote:
I would completely avoid CHS. My preference also runs to parted beats sfdisk beats fdisk (but note that modern fdisk is implemented on top of libparted).
What units are stored in the partition table?
IIRC an ms-dos disk label has LBA *or* CHS *or* both. WP would know.
$ parted /dev/sdq unit b print
~ # parted /dev/sdq unit b print Error: Can't have a partition outside the disk!
Whoops. I guess this is confirmation that there was a problem.
Salespitch: current-generation parted can also optimize for block alignment. This is off by default.
Shame pvresize doesn't take number of extents for its resize, that would have been more precise. Anyway:
It is, incidentally, an ongoing source of frustration for me that d-i's partman module only operates in SI units. So I tell it to allocate an LV 4G wide, and lvs reports 3.7g, so I then have to go back and lvextend to get it back up to a round number. (No, 4Gi of 4GiB doesn't work, at least as at Ubuntu 12.04.)
How do I update the partition table to end at the correct place? Am guessing this will require deleting the partition and re-adding it with fdisk, or is there a better way?
Unfortunately when parted has a hissy fit and refuses to print out the raw data, I don't know the best way to query it again. Normally I would ask parted to print in bytes, and give either bytes back again (when I want exact alignment), or percentages / GiB units when I want optimal alignment. If you ask parted to start at 0b, it will match more closely than if you ask it to match at 0% or 0GiB. I'm... ambivalent about this "feature".
Am a bit confused how this error occurred in the first place apparently was a standard Centos 5.x install. So maybe a bug in the installer?
Most likely case is you DD from a 2TB disk to another 2TB disk, but the new one is a little bit smaller. Or similar issues of that class.
On Fri, 14 Sep 2012, Brian May <brian@microcomaustralia.com.au> wrote:
Am a bit confused how this error occurred in the first place apparently was a standard Centos 5.x install. So maybe a bug in the installer?
Is there some reserved disk space? IDE disks can have some space reserved for "recovery". Linux can be made to recognise that or ignore it. If the reservation is ignored at installation time and then recognised later then it would result in a truncated partition. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (3)
-
Brian May -
Russell Coker -
Trent W. Buck