Bug#688757: pvmove onto disk with different sector size hazardous

[Daniel Pocock]

On 25/09/12 18:35, Bastian Blank wrote:
> On Tue, Sep 25, 2012 at 02:45:47PM +0200, Daniel Pocock wrote:
>> I have marked this `severe' because it has a high probability of
>> filesystem corruption and drives with 4096 byte sectors are likely to
>> become much more widespread.
> 
> This is a local problem. You have setup a filesystem with 512 bytes as
> block size (xfs I presume) and expect it to work on larger blocks? Just
> don't use xfs or kill the maintainer of xfs tools for still using such
> tiny blocks.

I have some 256MB ext3 filesystems.  They are mirrors of /boot
partitions from my servers.  e.g.

# tune2fs -l /dev/mapper/vg_ext-repl_diskABC

Filesystem features:      has_journal ext_attr resize_inode dir_index
filetype sparse_super
Block size:               1024
Fragment size:            1024
Filesystem created:        14:40:16 (December 2011)




>> I recently purchased a 3TB drive and created one big 3TB partition for lvm
> 
> Which brand and model? All large disks I obtained in the last year shows
> 512 bytes sectors.


Seagate  GoFlex Desk  (USB3 external 3.5" powered)
732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)

# fdisk /dev/sdf
Note: sector size is 4096 (not 512)

Command (m for help): p

Disk /dev/sdf: 3000.6 GB, 3000592977920 bytes
1 heads, 63 sectors/track, 11628041 cylinders, total 732566645 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1              63   732566582  2930266080   8e  Linux LVM



>> Many errors appeared during the pvmove operation
> 
> And this would be?

I somehow didn't capture them, but I'm fairly certain they were the same
as the errors I have now in dmesg

>> The old disk has 512 byte sectors and the new disk has 4096 byte sectors.
> 
> Please show smartctl -i $device.

/dev/sdf: Unknown USB bridge [0x0bc2:0x50a5 (0x100)]

# smartctl -d scsi -i /dev/sdf

Vendor:               Seagate
Product:              GoFlex Desk
Revision:             0D18
User Capacity:        3,000,592,977,920 bytes [3.00 TB]
Logical block size:   4096 bytes
Serial
Device type:          disk
Local Time is:        Tue Sep 25 20:14:21 2012 CEST


>> It appears that pvmove is potentially a lot more dangerous than the man
>> page suggests.  Although they were mounted during the pvmove, they were
>> not in use (they are backup filesystems and they only get written to on
>> demand).  If they had open files at the time, I suspect that corruption
>> would have occurred.
> 
> I doubt that, because the write would have been canceled.

A write could fail at a bad time, writes during the pvmove operation
might succeed at the end of the filesystem while failing at the front of
a filesystem.

>> Some potential ideas:
>> a) pvmove should check sector sizes and require --force if there is a
>> mismatch
> 
> Nope. This is up to the admin. Also lvm does not know about the
> filesystem.

Actually, there are probably a lot of admins who don't do this kind of
thing every day.  The passwd command asks the admin to type his new
password twice, there are many examples of tools that do basic safety checks

Note that in suggestion (a) I made no reference to the filesystem at
all, it is just to check the block device sector sizes.  E.g. if the
source device was 512 byte sectors and destination was 4096 byte
sectors, the pvmove would always need --force, even if the filesystem
was 4k blocks, because it would not be checking the filesystem block
size.  With --force, it would just go ahead and run.

In suggestion (b) I raised the possibility of filesystem block size
checks, but that was a separate point because it is more of a wish-list item