From: Jan Kara <jack@suse.cz>
To: Namjae Jeon <linkinjeon@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
Namjae Jeon <namjae.jeon@samsung.com>,
Ashish Sangwan <a.sangwan@samsung.com>,
Bonggil Bak <bgbak@samsung.com>
Subject: Re: [PATCH RESEND] udf: extent cache implementation for manipulating block map
Date: Wed, 22 Aug 2012 12:08:26 +0200 [thread overview]
Message-ID: <20120822100826.GB20640@quack.suse.cz> (raw)
In-Reply-To: <CAKYAXd_odZxzXqn91Q517BuRRFHP3O4pkVgN8uK6QTeFEqaEdg@mail.gmail.com>
On Wed 22-08-12 19:02:26, Namjae Jeon wrote:
> 2012/8/21, Jan Kara <jack@suse.cz>:
> Hi. Jan.
> Okay, We are trying to do it from your comment.
> 1. Change udf_ext_cache structure to following which would also include *bh.
> struct udf_ext_cache {
>
> /* Position of the cached extent */
> struct extent_position epos;
>
> /* Logical block where cached extent starts */
> sector_t block;
> };
OK.
> 2. Remove call to brelse(epos.bh) from all the callers of inode_bmap()
> and move it to udf_evict_inode()
It might be easier to keep brelse() where it is and add get_bh() to
udf_add_extent_cache() and brelse() to udf_clear_extent_cache(). It is then
easier to audit we don't leak bh references...
> 3. As now we are not caching elen, etype and eloc, we have to change
> the cache_hit logic in inode_bmap.
> The call to function udf_next_aext is now necessary from inode_bmap.
Yes.
> 4. Remove call to udf_clear_extent_cache() from udf_get_block as with
> new scheme, it is not required.
You still need this when you write before the cached location (e.g. when
the file has holes, and you write into them, extents will shift).
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2012-08-22 10:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-18 9:58 Namjae Jeon
2012-08-21 9:08 ` Jan Kara
2012-08-22 10:02 ` Namjae Jeon
2012-08-22 10:08 ` Jan Kara [this message]
2012-08-22 10:27 ` 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=20120822100826.GB20640@quack.suse.cz \
--to=jack@suse.cz \
--cc=a.sangwan@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=bgbak@samsung.com \
--cc=linkinjeon@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namjae.jeon@samsung.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
all inboxes | Powered by JetHome®