From: "Ragnar Kjørstad" <lvm@ragnark.vestdata.no>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] pv_move_pe() error again :/
Date: Mon, 10 Sep 2001 10:39:52 +0200 [thread overview]
Message-ID: <20010910103952.B31660@vestdata.no> (raw)
In-Reply-To: <E15gELn-0004OG-00@hermes.sistina.com>; from fejf@gmx.de on Mon, Sep 10, 2001 at 01:51:37AM +0200
On Mon, Sep 10, 2001 at 01:51:37AM +0200, FEJF wrote:
> Ragnar Kjørstad, on Montag, 12. September 2001 00:16 wrote:
> > OK, this is the patch.
>
> thx, for your help, but meanwhile i got one from Holger Grothe.
> sorry, but i haven't had time to post it earlier. i do it now because it has
> some advantages...
>
> tools/lib/pv_move.c:
>
> replace:
> fprintf ( stderr, "%s -- ERROR reading input "
> "physical volume \"%s\" (still %d bytes to read)\n
> cmd, vg->pv[src_pv_index]->pv_name, size);
> pe_unlock ( vg->vg_name);
> ret = -LVM_EPV_MOVE_PE_READ_IN;
> goto pv_move_pe_end;
> with:
> fprintf ( stderr, "read: %ld, to_read %ld\n", red, to_read);
> memset(buffer,170,to_read);
> red=to_read;
>
> with 170 u can chosse with which chars the bad block should be replaced with.
> (you can search filez for them later if u want - and have enough time ;)
It's better than my patch, but still not "correct":
* In my case pe_lock() failed, so it had to be "removed" as well. Was
that not the case for you?
* ret==-1 and ret<to_read should probably be handled differently.
* For ret>0 && ret<to_read the regular execution path could be followed.
* When red==-1 there should be a seek on pv[src_pv_index], so the
possition of the filehandle is set correctly. (now it's undefined)
* maybe red=SECTOR_SIZE; would be better? see next comment.
> tools/pvmove.c:
>
> replace:
> int buffer_size = 64*1024;
> with:
> int buffer_size = 512;
>
> this is an advantage to your patch, because pvmove then copys only 512
> byte-blocks and if there's only one block damaged u don't loose 64kb data.
> this has one disadvantage: it's SLOW... and slower than that ;)
This is not needed if the read loop is allowed to continue.
It would be great if someone took this patch, made the proposed changes,
and integrated it into the standard tools with an "ingore-read-errors"
flag... hint hint.
--
Ragnar Kjørstad
Big Storage
next prev parent reply other threads:[~2001-09-10 8:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-06 15:28 [linux-lvm] pv_move_pe() error again :/ FEJF
2001-09-06 20:05 ` Ragnar Kjørstad
2001-09-06 23:41 ` FEJF
2001-09-07 9:43 ` Ragnar Kjørstad
2001-09-07 11:36 ` FEJF
2001-09-09 22:16 ` Ragnar Kjørstad
2001-09-09 23:51 ` FEJF
2001-09-10 8:39 ` Ragnar Kjørstad [this message]
2001-09-10 11:27 ` Heinz J . Mauelshagen
2001-09-10 11:45 ` FEJF
2001-09-10 13:43 ` Heinz J . Mauelshagen
2001-09-10 13:49 ` FEJF
2001-09-10 15:38 ` Ragnar Kjørstad
2001-09-10 16:13 ` FEJF
2001-09-11 14:31 ` Heinz J . Mauelshagen
2001-09-11 17:26 ` Ragnar Kjørstad
2001-09-10 11:53 ` FEJF
2001-09-07 10:46 ` Heinz J . Mauelshagen
2001-09-07 11:45 ` FEJF
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010910103952.B31660@vestdata.no \
--to=lvm@ragnark.vestdata.no \
--cc=linux-lvm@sistina.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.