All of lore.kernel.org
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: "Steve Magnani" <steve@digidescorp.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] fat (exportfs): reconnect file handles to evicted inodes/dentries
Date: Thu, 05 Jul 2012 12:59:01 +0900	[thread overview]
Message-ID: <87a9zeeu4a.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <WC20120704180312.82023C@digidescorp.com> (Steve Magnani's message of "Wed, 04 Jul 2012 13:03:12 -0500")

"Steve Magnani" <steve@digidescorp.com> writes:

>> And can you add explanation the test of this? What were tested?
>
> I set up a memory-limited virtual machine with a 2 GB FAT partition 
> containing a kernel tree (~770 MB, ~40000 files, 9 levels) and did some 
> 'cp -r' and 'ls -lR' operations on it, some overlapping, some not.

Sounds good. It would be useful to add to changelog.

>> Please don't add new lock_super() usage if it is not necessary. Almost
>> all of lock_super() just replaced lock_kernel() usage. It rather should
>> be removed in future.  Probably, this should use inode->i_mutex
>> instead.
>
> I will look into this. My concern was freezing the filesystem while we 
> walk the on-disk structures. Also I developed this patch against 2.6.35 
> (the Bad Old BKL days) and ported it forward to 3.5.

I see.

>> BTW, the above issue is same with all of directory read.
>> 
>> And although this is using i_pos, is there no possibility to be passed
>> the detached inode (i.e. open but unlinked inode, i_pos == 0)?
>
> It is possible, that's why I added code to fall back to using logstart.
>
> I may yet rip out the get_name code. The testing I did before posting the 
> patch seemed to indicate that it was needed - I saw ESTALE errors without 
> get_name support that I did not see with it present. But I've been 
> digging into this some more and I think that was just a coincidence; 
> probably I just generated more extreme memory pressure when testing 
> without get_name. I should know more tomorrow.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

  reply	other threads:[~2012-07-05  3:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-03 19:09 [PATCH 0/2] fat (exportfs): fix NFS file handle decode Steven J. Magnani
2012-07-03 19:09 ` [PATCH 1/2] fat (exportfs): drop ineffective get_parent code Steven J. Magnani
2012-07-04 10:30   ` OGAWA Hirofumi
2012-07-03 19:09 ` [PATCH 2/2] fat (exportfs): reconnect file handles to evicted inodes/dentries Steven J. Magnani
2012-07-04 11:07   ` OGAWA Hirofumi
2012-07-04 18:03     ` Steve Magnani
2012-07-05  3:59       ` OGAWA Hirofumi [this message]
2012-07-05 20:03         ` Steven J. Magnani
2012-07-06 20:33     ` Steven J. Magnani
2012-07-06 21:07       ` OGAWA Hirofumi
2012-07-07  1:16         ` Steven J. Magnani
2012-07-07  6:03           ` OGAWA Hirofumi
2012-07-07 16:41             ` Steven J. Magnani
2012-07-07 17:00               ` OGAWA Hirofumi
2012-07-09 12:03                 ` Steven J. Magnani
2012-07-09 13:43                   ` OGAWA Hirofumi
2012-07-09 14:47                     ` Steven J. Magnani
2012-07-09 16:10                       ` OGAWA Hirofumi
2012-07-09 16:27                         ` Steven J. Magnani
2012-07-09 17:09                           ` Steven J. Magnani
2012-07-09 17:23                             ` Steven J. Magnani
2012-07-09 19:10                             ` OGAWA Hirofumi
2012-07-09 20:26                               ` Steven J. Magnani
2012-07-09 21:34                                 ` OGAWA Hirofumi
2012-07-09 22:03                                   ` Steven J. Magnani
2012-07-09 22:17                                     ` OGAWA Hirofumi

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=87a9zeeu4a.fsf@devron.myhome.or.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steve@digidescorp.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 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.