align lv_on_disk.base to 512K blocks
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Done.
How far are you with your driver enhancements?
Regards,
Heinz
Quoted 34 lines · Christoph Hellwig
Quoted 8 lines · Christoph Hellwig
Hi Heinz,
this patch makes vgcreate align the lv structures to 512K on disk, this makes reading them from kernel using bread much easier.
Could you apply it to 0.9?
Christoph
Sorry, forgot to attach the patch ;)
Here it is:
Christoph
Signature · 1 line
Always remember that you are unique. Just like everyone else.vg_setup_for_create.c renamed from vg_setup_for_create.c~ +1
-0@@ -43,6 +43,7 @@int ret =0 ;uint pe_total =0 ;ulong rest =0 ; +ulong size =0 ;#ifdef DEBUG debug_enter ("vg_setup_for_create -- CALLED\n" );@@ -89,8 +90,11 @@ vg->pv[p]->vg_on_disk.size =LVM_VG_DISK_SIZE ; vg->pv[p]->pv_namelist_on_disk.base =LVM_PV_NAMELIST_DISK_BASE ; vg->pv[p]->pv_namelist_on_disk.size = ( max_pv +1 ) *NAME_LEN ;
vg_setup_for_create.c line 100
Quoted 10 lines
vg_setup_for_create.c renamed from vg_setup_for_create.c~ +5
-2- vg->pv[p]->lv_on_disk.base = vg->pv[p]->pv_namelist_on_disk.base + - vg->pv[p]->pv_namelist_on_disk.size; + + size = vg->pv[p]->pv_namelist_on_disk.base + vg->pv[p]->pv_namelist_on_disk.size; + vg->pv[p]->lv_on_disk.base = (size /SECTOR_SIZE ) *SECTOR_SIZE ; +if (size %SECTOR_SIZE ) + vg->pv[p]->lv_on_disk.base +=SECTOR_SIZE ; vg->pv[p]->lv_on_disk.size = ( max_lv +1 ) *sizeof ( lv_t);LVM_PE_ON_DISK_BASE ( vg->pv[p]);strcpy ( vg->pv[p]->vg_name, vg->vg_name);
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Bartningstr. 12
64289 Darmstadt
Germany
[email protected] +49 6151 7103 86
FAX 7103 96=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Quoted 4 lines · Heinz J. Mauelshagen
Done.
How far are you with your driver enhancements?
As far as the in-kernel scanning is concerned I'm working on getting the detection of vgs with multiple pvs right and implement some kind of error handling.
Christoph
Signature · 1 line
Always remember that you are unique. Just like everyone else.
Quoted 9 lines · Christoph Hellwig
Quoted 4 lines · Heinz J. Mauelshagen
Done.
How far are you with your driver enhancements?
As far as the in-kernel scanning is concerned I'm working on getting the detection of vgs with multiple pvs right and implement some kind of error handling.
Cool, when development is done for a new version of LVM, please someone should also consider the hardware block size issue of the used PVs(I don't want to bring anyone from his way, just give an item for people that are looking for something).
One Architecture I just got LVM running on is S/390. Most of the block devices on this archtecture have an hardware block size of 4096 bytes and the LVM patches I've seen yet do not deal with that, they assume block sizes of BLOCK_SIZE.
To get LVM running there, I have initialized the lvm_blocksizes array with 4096 instead of BLOCK_SIZE. This forces the block accesses from userland to use 4k buffers and you can actually initialze an LV this way.
Then you also have to initialize the hardsect_size array with the same size, because the filesystems call bread directly and use this array to determine the size of the buffers used.
See fs/ext2/super.c and look for "hard". So you have to export the blocksizes of the PVs mapped in an LV to the upper layers thru the blksize_size and hardsect_size arrays as described above or you cannot mount an ext2 in that LV.
Of course, what I did was just a kludge to get me up and running, I think it should be better to ensure that only PVs that support the same block size can be used in an VG and be mapped to LVs.
I don't know the LVM structures and internal procedures good enough to do that myself, but maybe someone else can do or point me the the places where this would need to be checked and where I can determine the block size an LV will need to export.
best regards,
Bernd
PS: Again, nobody should delay work on in-kernel scanning of vgs for that, for me it's just working, and I'm just want to bring this information up too. Maybe it can intetrate into the next version and we have an LVM that works everywhere whithout any patch, that's the intention of this mail.