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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
