[Debian-ha-maintainers] Bug#612024: Bug#612024: DETAILS: gfs2-tools: File corruption when copying large files to gfs filesystem

[Olaf Reitmaier Veracierta]

Hi,

It is not the solution because I have two servers using the same GFS2
partition.

I've done what you said (lock_nolock) but, in that case, I prefer to use
EXT3 filesystem to store my files.

Still having replicable corruption problems with large file (>6GB) on GFS2
filesystems.

¿It means you can't handle large files on GFS2?

On Sun, Feb 6, 2011 at 5:22 PM, Guido Günther <agx at sigxcpu.org> wrote:

> On Sat, Feb 05, 2011 at 04:16:10PM +1930, Olaf Reitmaier Veracierta wrote:
> > Tests that have been made with files over 6GB in a server with LVM
> > partitions containing EXT3 and GFS2 filesystems (LVM partitions are
> > distributed over a SAN and LOCAL DISK).
> >
> > 1) Copy from LOCAL DISK (EXT3) to LOCAL DISK (EXT3). Result: OK.
> >
> > 2) Copy from LOCAL DISK (EXT3) to LOCAL DISK (GFS2). Result: OK.
> >
> > 3) Copy from LOCAL DISK (EXT3) to SAN (EXT3). Result: OK.
> >
> > 4) Copy from LOCAL DISK (EXT3) to SAN (GFS2). Result: BAD (Always with
> large
> > files).
> >
> > Then BAD qualification was done using both md5sum and sha1sum.
> >
> > If the SAN or QLOGIC firmware from the FC NIC is the problem then why
> with
> > EXT3 filesystems errors never appears and all files are copied
> correctly?.
>
> Anything in the kernel log or does this happen silently? Could you
> create a gfs2 filesystem with lock_nolock
>
>  $ mkfs -t gfs2 -p lock_nolock -j 1 /dev/block_device
>  $ mount -t gfs2 /dev/block_device /dir
>
> and try to reproduce?
> Cheers,
>  -- Guido
>



-- 
   "You don't know where your shadow will fall",
        Somebody.-
----------------------------------------------------------------
  Olaf Reitmaier Veracierta <olafrv at gmail.com>
----------------------------------------------------------------
            http://www.olafrv.com
----------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-ha-maintainers/attachments/20110212/359bb5f1/attachment.htm>