From: Glauber de Oliveira Costa <gocosta@br.ibm.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Glauber de Oliveira Costa <gocosta@br.ibm.com>,
"ext2-devel@lists.sourceforge.net"
<ext2-devel@lists.sourceforge.net>,
ext2resize-devel@lists.sourceforge.net,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org,
Andreas Dilger <adilger@clusterfs.com>,
Andrew Morton <akpm@osdl.org>,
Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Subject: Re: [PATCH] Ext3 online resizing locking issue
Date: Wed, 31 Aug 2005 08:35:06 -0300 [thread overview]
Message-ID: <20050831113506.GM23782@br.ibm.com> (raw)
In-Reply-To: <1125410818.1910.52.camel@sisko.sctweedie.blueyonder.co.uk>
>
> The two different uses of the superblock lock are really quite
> different; I don't see any particular problem with using two different
> locks for the two different things. Mount and the namespace code are
> not locking the same thing --- the fact that the resize code uses the
> superblock lock is really a historical side-effect of the fact that we
> used to use the same overloaded superblock lock in the ext2/ext3 block
> allocation layers to guard bitmap access.
>
>
At a first look, i thought about locking gdt-related data. But in a
closer one, it seemed to me that we're in fact modifying a little bit
more than that in the resize code. But all these modifications seem to
be somehow related to the ext3 super block specific data in
ext3_sb_info. My first naive approach would be adding a lock to that
struct
Besides that, by doing that, we become pretty much independent of vfs
locking decisions to handle ext3 data. Do you think it all make sense?
--
=====================================
Glauber de Oliveira Costa
IBM Linux Technology Center - Brazil
gocosta@br.ibm.com
=====================================
WARNING: multiple messages have this Message-ID (diff)
From: Glauber de Oliveira Costa <gocosta@br.ibm.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Glauber de Oliveira Costa <gocosta@br.ibm.com>,
"ext2-devel@lists.sourceforge.net"
<ext2-devel@lists.sourceforge.net>,
ext2resize-devel@lists.sourceforge.net,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org,
Andreas Dilger <adilger@clusterfs.com>,
Andrew Morton <akpm@osdl.org>,
Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Subject: Re: [PATCH] Ext3 online resizing locking issue
Date: Wed, 31 Aug 2005 08:35:06 -0300 [thread overview]
Message-ID: <20050831113506.GM23782@br.ibm.com> (raw)
In-Reply-To: <1125410818.1910.52.camel@sisko.sctweedie.blueyonder.co.uk>
>
> The two different uses of the superblock lock are really quite
> different; I don't see any particular problem with using two different
> locks for the two different things. Mount and the namespace code are
> not locking the same thing --- the fact that the resize code uses the
> superblock lock is really a historical side-effect of the fact that we
> used to use the same overloaded superblock lock in the ext2/ext3 block
> allocation layers to guard bitmap access.
>
>
At a first look, i thought about locking gdt-related data. But in a
closer one, it seemed to me that we're in fact modifying a little bit
more than that in the resize code. But all these modifications seem to
be somehow related to the ext3 super block specific data in
ext3_sb_info. My first naive approach would be adding a lock to that
struct
Besides that, by doing that, we become pretty much independent of vfs
locking decisions to handle ext3 data. Do you think it all make sense?
--
=====================================
Glauber de Oliveira Costa
IBM Linux Technology Center - Brazil
gocosta@br.ibm.com
=====================================
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
next prev parent reply other threads:[~2005-08-31 11:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-24 21:03 [PATCH] Ext3 online resizing locking issue Glauber de Oliveira Costa
2005-08-25 19:02 ` Stephen C. Tweedie
2005-08-25 19:02 ` Stephen C. Tweedie
2005-08-25 20:43 ` Glauber de Oliveira Costa
2005-08-30 14:06 ` Stephen C. Tweedie
2005-08-30 14:06 ` Stephen C. Tweedie
2005-08-31 11:35 ` Glauber de Oliveira Costa [this message]
2005-08-31 11:35 ` Glauber de Oliveira Costa
2005-08-31 13:30 ` Stephen C. Tweedie
2005-09-01 23:04 ` [PATCH][RFC] Ext3 online resizing locking issue (Again) Glauber de Oliveira Costa
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=20050831113506.GM23782@br.ibm.com \
--to=gocosta@br.ibm.com \
--cc=adilger@clusterfs.com \
--cc=akpm@osdl.org \
--cc=ext2-devel@lists.sourceforge.net \
--cc=ext2resize-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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.