public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Bill O'Donnell <billodo@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 2/2 v2] xfs_repair: new secondary superblock search method] xfs_repair: new secondary superblock search method
Date: Wed, 10 Feb 2016 09:51:03 -0600	[thread overview]
Message-ID: <56BB5C67.6040906@sandeen.net> (raw)
In-Reply-To: <20160210154300.GA9472@redhat.com>

On 2/10/16 9:43 AM, Bill O'Donnell wrote:
>> I'd make __find_secondary_sb() take (sb, start, skip) i.e. send in
>> > this:
>> > 
>>> > > +	retval = __find_secondary_sb(rsb, agsize, agsize);
>>> > > +	if (!retval)  {
>>> > > +		/*
>>> > > +		 * fallback: use minimum agsize for skipsize
>>> > > +		 */
>>> > > +		retval = __find_secondary_sb(rsb, XFS_AG_MIN_BYTES, BSIZE);
>>> > > +	}
>> > 
>> > and the function is something like:
>> > 
>> > static int
>> > __find_secondary_sb(
>> >         xfs_sb_t	*rsb,
>> > 	xfs_off_t	start,
>> >         xfs_off_t	skip)
>> > 
>> > {
>> > 
>> > ...
>> > 
>> >         for (done = 0, off = start; !done ; off += skip)  {
>> > ...
>> >                if (lseek64(x.dfd, off, SEEK_SET) != off)
>> >                         done = 1;
>> > 
>> >                if (!done && (read(x.dfd, sb, BSIZE)) <= 0)
>> >                         done = 1;
> But, bsize is used here:
> ...
>      	    * check the buffer 512 bytes at a time since
> 	    * we don't know how big the sectors really are.
> 	    */
> 	    for (i = 0; !done && i < bsize; i += BBSIZE)  {
> ...
> so, don't we still need to populate bsize? Or does it make more
> sense to just use BBSIZE in the conditional, ala:
>             for (i = 0; !done && i < BBSIZE; i += BBSIZE) 

Oh, right, sorry.  yes, keep the assignment:

                if (!done && (bsize = read(x.dfd, sb, BSIZE)) <= 0)  {

That handles a short read at the end; we ask for BSIZE, actually
read bsize, and then we need to iterate over what actually got read
(bsize).

BSIZE, bsize ... clear as mud.  :(

-Eric

>> > 
>> > 
>> > because you really can't deduce both the starting point and the skip-ahead
>> > size from just one parameter.
> Agreed.
> Thanks for your thorough reviews :)
> Bill
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2016-02-10 15:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-10  1:34 [[PATCH 2/2 v2] xfs_repair: new secondary superblock search method] xfs_repair: new secondary superblock search method Bill O'Donnell
2016-02-10  4:49 ` [PATCH " Eric Sandeen
2016-02-10 15:43   ` Bill O'Donnell
2016-02-10 15:51     ` Eric Sandeen [this message]

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=56BB5C67.6040906@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=billodo@redhat.com \
    --cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox