* LVM thinp, mkfs "device is not properly aligned"
@ 2017-11-15 23:20 Chris Murphy
2017-11-16 0:07 ` Dave Chinner
0 siblings, 1 reply; 4+ messages in thread
From: Chris Murphy @ 2017-11-15 23:20 UTC (permalink / raw)
To: xfs list
# mkfs.xfs /dev/mapper/vg-timemachine
warning: device is not properly aligned /dev/mapper/vg-timemachine
Use -f to force usage of a misaligned device
kernel: 4.13.12-300.fc27.x86_64
xfsprogs-4.12.0-4.fc27.x86_64
Model Family: Seagate Barracuda 2.5 5400
Device Model: ST2000LM015-2E8174
Reproduce steps:
1. Partitioning of the physical device, partition 5 is the relevant one
# gdisk -l /dev/sda
Number Start (sector) End (sector) Size Code Name
1 2048 104859647 50.0 GiB 8300 fedoraroot
2 104859648 2252343295 1024.0 GiB FFFF brick1
3 2252343296 2252752895 200.0 MiB EF00 EFI System
4 2252752896 2254850047 1024.0 MiB 8300 fedoraboot
5 2254850048 3907029134 787.8 GiB 8E00 Linux LVM
2. Make sda5 a pv, create a vg, just defaults here.
3. create thin pool, and virtual size LV
# lvcreate -T vg/thintastic -L 700G
# lvcreate -V 200G -T vg/thintastic -n timemachine
4. That gets me here:
# pvs
PV VG Fmt Attr PSize PFree
/dev/sda5 vg lvm2 a-- <787.79g <83.62g
# vgs
VG #PV #LV #SN Attr VSize VFree
vg 1 3 0 wz--n- <787.79g <83.62g
# lvs
LV VG Attr LSize Pool Origin Data% Meta%
Move Log Cpy%Sync Convert
cryptoswap vg -wi-ao---- 4.00g
thintastic vg twi-aotz-- 700.00g 0.00 0.44
timemachine vg Vwi-a-tz-- 200.00g thintastic 0.00
# blockdev --getss /dev/mapper/vg-timemachine
512
# blockdev --getpbsz /dev/mapper/vg-timemachine
4096
# blockdev --getalignoff /dev/mapper/vg-timemachine
512
$ lsblk -t
pretty version (expires in 1 month)
https://pastebin.mozilla.org/9072860
for the list archive:
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC
ROTA SCHED RQ-SIZE RA WSAME
sda 0 4096 0 4096 512
1 cfq 128 128 0B
├─sda1 0 4096 0 4096 512
1 cfq 128 128 0B
├─sda2 0 4096 0 4096 512
1 cfq 128 128 0B
│ └─brick1 512 4096 0 4096 512
1 128 128 0B
├─sda3 0 4096 0 4096 512
1 cfq 128 128 0B
├─sda4 0 4096 0 4096 512
1 cfq 128 128 0B
└─sda5 0 4096 0 4096 512
1 cfq 128 128 0B
├─vg-cryptoswap 512 4096 0 4096 512
1 128 128 0B
│ └─swap 512 4096 0 4096 512
1 128 128 0B
├─vg-thintastic_tmeta 512 4096 0 4096 512
1 128 128 0B
│ └─vg-thintastic-tpool 512 524288 524288 4096 512
1 128 128 0B
│ ├─vg-thintastic 512 524288 524288 4096 512
1 128 128 0B
│ └─vg-timemachine 512 524288 524288 4096 512
1 128 128 0B
└─vg-thintastic_tdata 512 4096 0 4096 512
1 128 128 0B
└─vg-thintastic-tpool 512 524288 524288 4096 512
1 128 128 0B
├─vg-thintastic 512 524288 524288 4096 512
1 128 128 0B
└─vg-timemachine 512 524288 524288 4096 512
1 128 128 0B
So I have no idea what mkfs.xfs is complaining about being unaligned.
If I go ahead and use -f:
# mkfs.xfs -f /dev/mapper/vg-timemachine
warning: device is not properly aligned /dev/mapper/vg-timemachine
meta-data=/dev/mapper/vg-timemachine isize=512 agcount=16,
agsize=3276672 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=0,
rmapbt=0, reflink=0
data = bsize=4096 blocks=52426752, imaxpct=25
= sunit=128 swidth=128 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=25600, version=2
= sectsz=512 sunit=8 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
#
--
Chris Murphy
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: LVM thinp, mkfs "device is not properly aligned"
2017-11-15 23:20 LVM thinp, mkfs "device is not properly aligned" Chris Murphy
@ 2017-11-16 0:07 ` Dave Chinner
2017-11-16 2:19 ` Chris Murphy
0 siblings, 1 reply; 4+ messages in thread
From: Dave Chinner @ 2017-11-16 0:07 UTC (permalink / raw)
To: Chris Murphy; +Cc: xfs list
On Wed, Nov 15, 2017 at 04:20:59PM -0700, Chris Murphy wrote:
> # mkfs.xfs /dev/mapper/vg-timemachine
> warning: device is not properly aligned /dev/mapper/vg-timemachine
> Use -f to force usage of a misaligned device
That is emitted when blikid tells XFS that the device it is about to
format is not correctly aligned.
The check that is failing:
if (blkid_topology_get_alignment_offset(tp) != 0)
>From here:
https://www.kernel.org/pub/linux/utils/util-linux/v2.21/libblkid-docs/libblkid-Topology-information.html
ALIGNMENT_OFFSET: indicates how many bytes the beginning of the
device is offset from the disk's natural alignment.
....
> $ lsblk -t
>
(Trimmed for brevity and readability)
.....
> NAME ALIGNMENT MIN-IO OPT-IO
> sda 0 4096 0
> sda1 0 4096 0
> sda2 0 4096 0
> brick1 512 4096 0
> sda3 0 4096 0
> sda4 0 4096 0
> sda5 0 4096 0
> vg-cryptoswap 512 4096 0
> swap 512 4096 0
> vg-thintastic_tmeta 512 4096 0
> vg-thintastic-tpool 512 524288 524288
> vg-thintastic 512 524288 524288
> vg-timemachine 512 524288 524288
> vg-thintastic_tdata 512 4096 0
> vg-thintastic-tpool 512 524288 524288
> vg-thintastic 512 524288 524288
> vg-timemachine 512 524288 524288
>
What you can see here is that all the volume groups have a non-zero
alignment - they are all off by one sector - and that's what
mkfs.xfs is warning you about. i.e. something's not quite right at
the LVM layer....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: LVM thinp, mkfs "device is not properly aligned"
2017-11-16 0:07 ` Dave Chinner
@ 2017-11-16 2:19 ` Chris Murphy
2017-11-16 2:29 ` Chris Murphy
0 siblings, 1 reply; 4+ messages in thread
From: Chris Murphy @ 2017-11-16 2:19 UTC (permalink / raw)
To: Dave Chinner; +Cc: Chris Murphy, xfs list
On Wed, Nov 15, 2017 at 5:07 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Wed, Nov 15, 2017 at 04:20:59PM -0700, Chris Murphy wrote:
>> # mkfs.xfs /dev/mapper/vg-timemachine
>> warning: device is not properly aligned /dev/mapper/vg-timemachine
>> Use -f to force usage of a misaligned device
>
> That is emitted when blikid tells XFS that the device it is about to
> format is not correctly aligned.
>
> The check that is failing:
>
> if (blkid_topology_get_alignment_offset(tp) != 0)
>
> From here:
>
> https://www.kernel.org/pub/linux/utils/util-linux/v2.21/libblkid-docs/libblkid-Topology-information.html
>
> ALIGNMENT_OFFSET: indicates how many bytes the beginning of the
> device is offset from the disk's natural alignment.
>
> ....
>> $ lsblk -t
>>
> (Trimmed for brevity and readability)
> .....
>> NAME ALIGNMENT MIN-IO OPT-IO
>> sda 0 4096 0
>> sda1 0 4096 0
>> sda2 0 4096 0
>> brick1 512 4096 0
>> sda3 0 4096 0
>> sda4 0 4096 0
>> sda5 0 4096 0
>> vg-cryptoswap 512 4096 0
>> swap 512 4096 0
>> vg-thintastic_tmeta 512 4096 0
>> vg-thintastic-tpool 512 524288 524288
>> vg-thintastic 512 524288 524288
>> vg-timemachine 512 524288 524288
>> vg-thintastic_tdata 512 4096 0
>> vg-thintastic-tpool 512 524288 524288
>> vg-thintastic 512 524288 524288
>> vg-timemachine 512 524288 524288
>>
>
> What you can see here is that all the volume groups have a non-zero
> alignment - they are all off by one sector - and that's what
> mkfs.xfs is warning you about. i.e. something's not quite right at
> the LVM layer....
Something else is screwy here. Look under sda2/brick1 which is a
dm-crypt volume created with cryptsetup, not lvm. It also has this
alignment value of 512.
--
Chris Murphy
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: LVM thinp, mkfs "device is not properly aligned"
2017-11-16 2:19 ` Chris Murphy
@ 2017-11-16 2:29 ` Chris Murphy
0 siblings, 0 replies; 4+ messages in thread
From: Chris Murphy @ 2017-11-16 2:29 UTC (permalink / raw)
To: Chris Murphy; +Cc: Dave Chinner, xfs list
On Wed, Nov 15, 2017 at 7:19 PM, Chris Murphy <lists@colorremedies.com> wrote:
> On Wed, Nov 15, 2017 at 5:07 PM, Dave Chinner <david@fromorbit.com> wrote:
>> On Wed, Nov 15, 2017 at 04:20:59PM -0700, Chris Murphy wrote:
>>> # mkfs.xfs /dev/mapper/vg-timemachine
>>> warning: device is not properly aligned /dev/mapper/vg-timemachine
>>> Use -f to force usage of a misaligned device
>>
>> That is emitted when blikid tells XFS that the device it is about to
>> format is not correctly aligned.
>>
>> The check that is failing:
>>
>> if (blkid_topology_get_alignment_offset(tp) != 0)
>>
>> From here:
>>
>> https://www.kernel.org/pub/linux/utils/util-linux/v2.21/libblkid-docs/libblkid-Topology-information.html
>>
>> ALIGNMENT_OFFSET: indicates how many bytes the beginning of the
>> device is offset from the disk's natural alignment.
>>
>> ....
>>> $ lsblk -t
>>>
>> (Trimmed for brevity and readability)
>> .....
>>> NAME ALIGNMENT MIN-IO OPT-IO
>>> sda 0 4096 0
>>> sda1 0 4096 0
>>> sda2 0 4096 0
>>> brick1 512 4096 0
>>> sda3 0 4096 0
>>> sda4 0 4096 0
>>> sda5 0 4096 0
>>> vg-cryptoswap 512 4096 0
>>> swap 512 4096 0
>>> vg-thintastic_tmeta 512 4096 0
>>> vg-thintastic-tpool 512 524288 524288
>>> vg-thintastic 512 524288 524288
>>> vg-timemachine 512 524288 524288
>>> vg-thintastic_tdata 512 4096 0
>>> vg-thintastic-tpool 512 524288 524288
>>> vg-thintastic 512 524288 524288
>>> vg-timemachine 512 524288 524288
>>>
>>
>> What you can see here is that all the volume groups have a non-zero
>> alignment - they are all off by one sector - and that's what
>> mkfs.xfs is warning you about. i.e. something's not quite right at
>> the LVM layer....
>
>
> Something else is screwy here. Look under sda2/brick1 which is a
> dm-crypt volume created with cryptsetup, not lvm. It also has this
> alignment value of 512.
OK this hard drive was originally inside some kind of USB enclosure.
And it's giving off information that's confusing libblkid, resulting
in this problem. I've done a tear down of the LVM stuff, and as I've
built it back up again, this 512 byte offset is not present. I'll file
a bug report and see if there's a way to figure out whether there's a
software work around or if this is broken hardware.
--
Chris Murphy
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-11-16 2:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-15 23:20 LVM thinp, mkfs "device is not properly aligned" Chris Murphy
2017-11-16 0:07 ` Dave Chinner
2017-11-16 2:19 ` Chris Murphy
2017-11-16 2:29 ` Chris Murphy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).