All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcin Slusarz <marcin.slusarz@gmail.com>
To: Amit Sahrawat <amit.sahrawat83@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: UDF: alternate anchor block detection
Date: Tue, 4 Oct 2011 16:51:56 +0200	[thread overview]
Message-ID: <20111004145156.GA4183@joi.lan> (raw)
In-Reply-To: <CADDb1s3Ab18ppaDKeRYMnX9TSb_kHaj4T1wUA=FeNUjpxF2cRw@mail.gmail.com>

On Mon, Oct 03, 2011 at 05:16:15PM +0530, Amit Sahrawat wrote:
> While mounting UDF media, when the primary AVDP is not found at block
> 256, UDF code tries to read-in the alternate AVDP.
> In the function udf_find_anchor, udf_scan_anchors is called 3 times,
> where each call to udf_scan_anchors read 12 blocks.
> In case there is no alternate AVDP stored, a total of 36 blocks are
> read before mount fails - causing time delay for Mount Failure.
> 
> 1) After first call to udf_scan_anchors and before the second call
> there is varconv conversion, for the older drivers, which skips 7
> blocks after every 32 blocks. What are these older drivers? Do we
> still require this code?

I'm not sure what "drivers" are you talking about, but "UDF_SET_FLAG(sb,
UDF_FLAG_VARCONV)" does not convert anything - it just sets superblock
flag.

> 2) After varconv conversion, why is there a third call to
> udf_scan_anchors? In the 1st call and 3rd call to udf_scan_anchors,
> exactly same blocks are read, so this 3rd call seems to be redundant.

Because UDF_FLAG_VARCONV changes behavior of udf_scan_anchors.

Marcin

  reply	other threads:[~2011-10-04 14:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03 11:46 UDF: alternate anchor block detection Amit Sahrawat
2011-10-04 14:51 ` Marcin Slusarz [this message]
     [not found] <CAOiN93m2OUnv95jpCT++Edv0yCwWG1mWa6uAYsuk2MGjKHZpJQ@mail.gmail.com>
2011-10-06 21:50 ` UDF " Jan Kara
2011-10-06 23:08   ` NamJae Jeon

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=20111004145156.GA4183@joi.lan \
    --to=marcin.slusarz@gmail.com \
    --cc=amit.sahrawat83@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.