linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Alessio Igor Bogani <abogani@texware.it>, Jan Kara <jack@suse.cz>,
	Arnd Bergmann <arnd@arndb.de>, Tim Bird <tim.bird@am.sony.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] udf: Add missed protection for s_lvid_dirty
Date: Sun, 7 Nov 2010 15:14:03 +0100	[thread overview]
Message-ID: <20101107141403.GF5126@quack.suse.cz> (raw)
In-Reply-To: <20101106180530.GB13315@infradead.org>

On Sat 06-11-10 14:05:30, Christoph Hellwig wrote:
> On Sat, Nov 06, 2010 at 06:47:08PM +0100, Alessio Igor Bogani wrote:
> > As reported in udf_sb.h the udf_sb_infoi's structure member s_lvid_dirty should
> > be protected by s_alloc_mutex. Added that mutex on a couple of places where it
> > miss.
> 
> The whole s_lvid_dirty flag doesn't make any sense to me.  As a start it
> simply duplicates s_dirty in the VFS superblock, but even more it just
> controls the dirty state of s_lvid_bh.  I think you could simply kill
> s_lvid_dirty, plus s_dirty inside udf and replace all calls to
> udf_updated_lvid with a simple mark_buffer_dirty(sbi->s_lvid_bh) and
> also get rid of all the locking around it.
  Well, I should have probably commented more on it :). The problem is that
people sometimes tend to mount CD-RW with UDF filesystem directly under
Linux.  Now LVID is updated on each allocation so if you write to the media,
the block carrying LVID is written rather often (like once per 5 seconds or
so) which quickly deteriorates that block on the media.
  So we basically want to hide the dirty bit on that buffer from VFS so that
it does not write the block so often.
  Looking at it now, cleaner fix might be to move the counters to sbi and
write them to the LVID only during umount. So that might be a nice cleanup
as well.

> While looking at this I also noticed that large parts of udf_open_lvid
> and udf_close_lvid are basically duplicate.  The only difference seems
> to be setting an integrityType of LVID_INTEGRITY_TYPE_OPEN vs
> LVID_INTEGRITY_TYPE_CLOSE and updating a few revision counters on close.
> If you're interested in working on udf that seems like a nice little
> cleanup.
  Yes, that could be cleaned up.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2010-11-07 14:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-06 17:47 [PATCH 1/4] udf: Add missed protection for s_lvid_dirty Alessio Igor Bogani
2010-11-06 17:47 ` [PATCH 2/4] udf: Remove unnecessary bkl usages Alessio Igor Bogani
2010-11-06 18:06   ` Christoph Hellwig
2010-11-06 17:47 ` [PATCH 3/4] udf: Replace bkl with a mutex for protect udf_inode_info struct Alessio Igor Bogani
2010-11-06 18:10   ` Christoph Hellwig
2010-11-06 17:47 ` [PATCH 4/4] udf: Replace bkl with a mutex for protect udf_sb_info struct Alessio Igor Bogani
2010-11-06 18:16   ` Christoph Hellwig
2010-11-06 18:05 ` [PATCH 1/4] udf: Add missed protection for s_lvid_dirty Christoph Hellwig
2010-11-07 14:14   ` Jan Kara [this message]
2010-11-07 14:27     ` Christoph Hellwig
2010-11-07 15:06 ` Jan Kara
2010-11-15 22:46 ` Arnd Bergmann
2010-11-16  0:43   ` Jan Kara
2010-11-16 13:03     ` Alessio Igor Bogani

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=20101107141403.GF5126@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=abogani@texware.it \
    --cc=arnd@arndb.de \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tim.bird@am.sony.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;
as well as URLs for NNTP newsgroup(s).