ext2resize-devel

[ext2resize] Ext2resize for big-endian (Ultrasparc)

[Dave W. <da...@xs...>]

Hi all,

I recently installed LVM on a Sun E450 and was experimenting with
ext2resize.  After extending the logical volume, I extended my ext2
filesystem, at least that was they idea.

After messing up the filesystem a couple of times, I finally noticed
the little TODO list for ext2resize:

misc todo
---------
make it work on big-endian systems.


Hmm.... not really supported yet.

I would like to work on making ext2resize work on big-endian (specifically
(ultra)sparc), but although I can hack a little C code, I have no idea
where to start on making ext2resize big-endian compliant.

Any pointers for starting to make this util work on big-endian are
appreciated.

-Dave

-- 
Dave Wapstra
da...@xs...

Re: [ext2resize] Ext2resize for big-endian (Ultrasparc)

[Andreas D. <ad...@tu...>]

Dave Wapstra writes:
> I recently installed LVM on a Sun E450 and was experimenting with
> ext2resize.  After extending the logical volume, I extended my ext2
> filesystem, at least that was they idea.
> 
> After messing up the filesystem a couple of times, I finally noticed
> the little TODO list for ext2resize:
> 
> misc todo
> ---------
> make it work on big-endian systems.

I'm surprised you were even able to mess up the filesystem!!!  It should
have failed when checking the EXT2_MAGIC in the superblock, because of
endian issues (at least that's what I assumed).  I will have to ensure
that we refuse to do anything on big-endian machines until this works
properly.

> I would like to work on making ext2resize work on big-endian (specifically
> (ultra)sparc), but although I can hack a little C code, I have no idea
> where to start on making ext2resize big-endian compliant.

There are two ways to do this, and I'm not sure which is best:

1) leave the superblock and all on-disk data in little-endian format,
   and convert to machine endianness as needed.  This is done in the kernel,
   but it may be because they are directly mapping on-disk data and have
   no control over when it is written to disk.

2) Convert the superblock and all on-disk data to machine endianness when
   it is read from disk.  This would require new routines for read_super,
   read_GDT, read_inode, etc.  This is what's done in the e2fsprogs
   libext2fs.  There are a few cases (with data that isn't repeatedly
   accessed, like directory entries) where it keeps the data little-endian.

It is worthwhile to hear from Andrew Clausen (parted author and user of
a divergent libext2resize) to see what he has done in this regard.  We
could merge the endianness changes back into libext2resize.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [ext2resize] Ext2resize for big-endian (Ultrasparc)

[Dave W. <da...@xs...>]

On 21 March, 2001 at 14:14:58 -0700, Andreas Dilger <ad...@tu...> wrote:
> 
> Dave Wapstra writes:
> > After messing up the filesystem a couple of times, I finally noticed
> > the little TODO list for ext2resize:
> 
> I'm surprised you were even able to mess up the filesystem!!!  It should
> have failed when checking the EXT2_MAGIC in the superblock, because of
> endian issues (at least that's what I assumed).  I will have to ensure
> that we refuse to do anything on big-endian machines until this works
> properly.

Well, maybe I should say Volume Group instead of filesystem. Here's what I did:

Created logical volume, made ext2 filesytem, extended logical volume)

[/root]# pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/sdb" of VG "ftp" [8.43 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/sdc" of VG "ftp" [8.43 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/sdd" of VG "ftp" [8.43 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/sde" of VG "ftp" [8.43 GB / 72 MB free]
pvscan -- total: 4 [33.74 GB] / in use: 4 [33.74 GB] / in no VG: 0 [0]

[/root]# ext2resize /dev/ftp/lvol1 33g
ext2resize v1.1.15 - 2000/08/08 for EXT2FS 0.5b
ext2resize: ext2_open: invalid superblock
ext2resize: can't open /dev/ftp/lvol1
[/root]# pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/sdb"   is associated to an unknown VG (run vgscan)
pvscan -- ACTIVE   PV "/dev/sdc"   is associated to an unknown VG (run vgscan)
pvscan -- ACTIVE   PV "/dev/sdd"   is associated to an unknown VG (run vgscan)
pvscan -- ACTIVE   PV "/dev/sde"   is associated to an unknown VG (run vgscan)
pvscan -- total: 4 [33.74 GB] / in use: 4 [33.74 GB] / in no VG: 0 [0]

Note: this output is edited, but does show the problem.  After this, I get 

vgcreate -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan

and have to do dd if=/dev/zero of=/dev/sd<x> to clear all the tables
and do a reboot to clean up the VGDA in the kernel

I'll give GNU parted a try.


-Dave

-- 
Dave Wapstra
da...@xs...

Re: [ext2resize] Ext2resize for big-endian (Ultrasparc)

[Andreas D. <ad...@tu...>]

Dave Wapstra writes:
> On 21 March, 2001 at 14:14:58 -0700, Andreas Dilger <ad...@tu...> wrote:
> Well, maybe I should say Volume Group instead of filesystem. Here's what I did:
> 
> Created logical volume, made ext2 filesytem, extended logical volume)
> 
> [/root]# pvscan
> pvscan -- reading all physical volumes (this may take a while...)
> pvscan -- ACTIVE   PV "/dev/sdb" of VG "ftp" [8.43 GB / 0 free]
> pvscan -- ACTIVE   PV "/dev/sdc" of VG "ftp" [8.43 GB / 0 free]
> pvscan -- ACTIVE   PV "/dev/sdd" of VG "ftp" [8.43 GB / 0 free]
> pvscan -- ACTIVE   PV "/dev/sde" of VG "ftp" [8.43 GB / 72 MB free]
> pvscan -- total: 4 [33.74 GB] / in use: 4 [33.74 GB] / in no VG: 0 [0]
> 
> [/root]# ext2resize /dev/ftp/lvol1 33g
> ext2resize v1.1.15 - 2000/08/08 for EXT2FS 0.5b
> ext2resize: ext2_open: invalid superblock
> ext2resize: can't open /dev/ftp/lvol1
> [/root]# pvscan
> pvscan -- reading all physical volumes (this may take a while...)
> pvscan -- ACTIVE   PV "/dev/sdb"   is associated to an unknown VG (run vgscan)
> pvscan -- ACTIVE   PV "/dev/sdc"   is associated to an unknown VG (run vgscan)
> pvscan -- ACTIVE   PV "/dev/sdd"   is associated to an unknown VG (run vgscan)
> pvscan -- ACTIVE   PV "/dev/sde"   is associated to an unknown VG (run vgscan)
> pvscan -- total: 4 [33.74 GB] / in use: 4 [33.74 GB] / in no VG: 0 [0]
> 
> Note: this output is edited, but does show the problem.  After this, I get 
> 
> vgcreate -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
> 
> and have to do dd if=/dev/zero of=/dev/sd<x> to clear all the tables
> and do a reboot to clean up the VGDA in the kernel

It may very well be that this is an LVM problem.  As you can see, ext2resize
doesn't even succeed in opening the filesystem, so I don't see how it can
corrupt the LVM (actually, it is impossible that writing into /dev/ftp/lvol1
would corrupt LVM metadata (without an LVM bug), because the LVM metadata
is outside the LV itself.

I see you are using Ultrasparc - you need basically todays -ac kernel (or
the Ultrasparc patch from LVM CVS) in order to have LVM work properly on
Ultrasparc.  You also need current CVS LVM kernel patches to have anything
resembling a useful LVM system (I also do a lot of LVM development).  Even
so, I don't think this has seen a lot of testing yet.

Please see if the above (omitted) steps cause LV corruption without any
ext2resize involved.  Please post any findings to the LVM mailing list
lin...@li... (you need to subscribe first).  It would be
useful to see what you have cut out of your process here.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [ext2resize] Ext2resize for big-endian (Ultrasparc)

[Andrew C. <cl...@gn...>]

Dave Wapstra wrote:
> I recently installed LVM on a Sun E450 and was experimenting with
> ext2resize.  After extending the logical volume, I extended my ext2
> filesystem, at least that was they idea.
> 
> After messing up the filesystem a couple of times, I finally noticed
> the little TODO list for ext2resize:
> 
> misc todo
> ---------
> make it work on big-endian systems.

GNU Parted's ext2 resizer (which forked from ext2resize) supports
big-endian machines.  It is stable, i.e. has gone through a
stable release, and has been available as such for about half a year.

	ftp.gnu.org/gnu/parted

Parted can't do online resizing.  Also, you will probably want to
read the section on LVM in the manual...

Andrew Clausen

Re: [ext2resize] Ext2resize for big-endian (Ultrasparc)

[Dave W. <da...@xs...>]

On 22 March, 2001 at 21:25:33 +1100, Andrew Clausen <cl...@gn...> wrote:
> 
> GNU Parted's ext2 resizer (which forked from ext2resize) supports
> big-endian machines.  It is stable, i.e. has gone through a
> stable release, and has been available as such for about half a year.

I downloaded the latest source (1.4.10) but it doesn't seem to recognize
my partitions, even on a normal scsi drive (no LVM). See the difference
between the parted output and good old fdisk. Am I missing something?

(parted) print
Disk geometry for /dev/sda: 0.000-8637.337 megabytes
Disk label type: loop
Minor    Start       End     Filesystem  Flags
1          0.000   8637.337  ext2        
(parted) 


Command (m for help): p

Disk /dev/sda (Sun disk label): 27 heads, 133 sectors, 4924 cylinders
Units = cylinders of 3591 * 512 bytes

   Device Flag    Start       End    Blocks   Id  System
/dev/sda1             0      1426   2560316+  83  Linux native
/dev/sda2          1426      2852   2560383   83  Linux native
/dev/sda3             0      4924   8841042    5  Whole disk
/dev/sda4          2852      3423   1025230+  83  Linux native
/dev/sda5          3423      3716    526081+  82  Linux swap
/dev/sda6          3716      3774    104139   83  Linux native
/dev/sda7          3774      3832    104139   83  Linux native

Command (m for help): 


-Dave

-- 
Dave Wapstra
da...@xs...