linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jérémy Cochoy" <jeremy.cochoy@gmail.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Liuweni <qingshenlwy@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	strongzgy <strongzgy@gmail.com>, xgr178 <xgr178@163.com>,
	Liu Hui <onlyflyer@gmail.com>, viro <viro@zeniv.linux.org.uk>,
	akpm <akpm@linux-foundation.org>, jack <jack@suse.cz>,
	npiggin <npiggin@suse.de>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 1/3]fs/inode: iunique() Optimize Performance
Date: Wed, 25 Nov 2009 20:20:02 +0100	[thread overview]
Message-ID: <a229bc400911251120y220066afjb10d391198c5807c@mail.gmail.com> (raw)
In-Reply-To: <20091125141505.GH9482@parisc-linux.org>

Hello,

There is something strange in iunique : what will happend if all inode
between max_reserved+1 and (unsinged in)(0-1) ? Will it make an
infinite loop or an interruption can happen and make an inode become
free?

In that case, it will be better to stop search when counter overflow, no?

Will it not be better to use a field max_ino_used (in superblock, for
exemple) where we store the last inode allocated with iunique and make
a search only if max_ino_used become to (unsigned)(-1) ?

But, if iunique is here to provide a solution in order to generate
unused inode in filesystem which have various inode number, it's
better to use a list of used ino, in a short hash table which use the
first 8 bits of the inode, always use the same function to create a
new inode and look at the head if we can add a new inode with bigger
ino and still in the range. (But i think filesystems developper prefer
to write ther own functions in order to do that, no?)

Well, if we want to stop in case of full inode filesystem, we can put
the first condition in the head and add change return as :
return inode->i_ino > max_reserved ? res : 0; // 0 might "i can't find
an inode after max_reserved"

2009/11/25 Matthew Wilcox <matthew@wil.cx>:
> On Wed, Nov 25, 2009 at 10:09:45PM +0800, Liuweni wrote:
>> ---
>> move the if condition out the while{}.
>> While the function executing, the if
>> condition won't check again and again.
>> And this code won't change the function
>> of iunique().
>
> That's not true.
>
>> @@ -838,9 +838,10 @@ ino_t iunique(struct super_block *sb, ino_t max_reserved)
>>       ino_t res;
>>
>>       spin_lock(&inode_lock);
>> +
>> +     if (counter <= max_reserved)
>> +             counter = max_reserved + 1;
>>       do {
>> -             if (counter <= max_reserved)
>> -                     counter = max_reserved + 1;
>>               res = counter++;
>
> 'counter' is incremented here, so if it wraps around, we'll blunder into
> the reserved space again.
>
>>               head = inode_hashtable + hash(sb, res);
>>               inode = find_inode_fast(sb, head, res);
>>
>>
>> --------------
>> Best Regards,
>> Liuweni
>> 2009-11-25
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> Matthew Wilcox                          Intel Open Source Technology Centre
> "Bill, look, we understand that you're interested in selling us this
> operating system, but compare it to ours.  We can't possibly take such
> a retrograde step."
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Jérémy Cochoy - L1 MI (Lyon1)
Mail : jeremy.cochoy@gmail.com
Tel : 06-43-01-74-02
Alias Zenol - http://zenol.fr

  reply	other threads:[~2009-11-25 19:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-25 14:09 [PATCH 1/3]fs/inode: iunique() Optimize Performance Liuweni
2009-11-25 14:15 ` Matthew Wilcox
2009-11-25 19:20   ` Jérémy Cochoy [this message]
2009-11-25 19:52     ` Matthew Wilcox
2009-12-01  5:01       ` liu weni
2009-12-01 12:03         ` Matthew Wilcox
2009-12-01 13:21           ` Liuweni
2009-12-01 14:00             ` Matthew Wilcox
2009-12-02  9:42               ` Nick Piggin
2009-11-25 14:51 ` Liuweni
2009-11-25 14:54   ` Matthew Wilcox
2009-11-25 15:06 ` Andi Kleen

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=a229bc400911251120y220066afjb10d391198c5807c@mail.gmail.com \
    --to=jeremy.cochoy@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=npiggin@suse.de \
    --cc=onlyflyer@gmail.com \
    --cc=qingshenlwy@gmail.com \
    --cc=strongzgy@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xgr178@163.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).