All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@parallels.com>
To: Mark Fasheh <mfasheh@suse.de>, <dsterba@suse.cz>
Cc: Andrew Vagin <avagin@gmail.com>,
	Chris Mason <chris.mason@fusionio.com>,
	<linux-btrfs@vger.kernel.org>, <kzak@redhat.com>,
	<xemul@openvz.org>
Subject: Re: btrfs: stat(2) and /proc/pid/maps returns different devices
Date: Thu, 24 Oct 2013 14:41:28 +0400	[thread overview]
Message-ID: <5268F958.60004@parallels.com> (raw)
In-Reply-To: <20130719205115.GK32502@wotan.suse.de>

On 07/20/2013 12:51 AM, Mark Fasheh wrote:
> On Thu, Jul 11, 2013 at 12:26:50AM +0200, David Sterba wrote:
>> On Wed, Jul 10, 2013 at 10:45:45AM -0700, Mark Fasheh wrote:
>>> Well, what do I get when I pretend I don't care any more? The little voice
>>> in my head says "keep plugging away". Here's another attempt at fixing this
>>> problem in a sane manner. Basically, this time we're adding a flag to
>>> s_flags which btrfs sets. Proc will see the flag and call ->getattr().
>>>
>>> This compiles, but it needs testing (which I will get to soon). It still has
>>> a bunch of problems in my honest opinion but maybe if we get something
>>> acceptable upstream we can work from there.
>>>
>>> Also, as Andrew pointed out there's more than one place which is return
>>> different device than from stat(2) so I probably need to update more sites
>>> to deal with this.
>>>
>>> Does anyone see a problem with this approach?
>>
>> The approach looks ok to me, the implementation is internal to vfs and
>> fairly minimal. The bit that bothers me is the name of the flag, it's
>> completely unobvious what it means.
> 
> I'll come up with something better for my next revision :)

Mark, David,

What are your plans about the next version? Any chance we can see it in the
3.13 merge window? (unless I've missed the fact, that it's already there)

I'd really love to see it, as this thing is a blocker for checkpoint-restore
on btrfs.

Thanks,
Pavel

  parent reply	other threads:[~2013-10-24 10:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-04  9:51 btrfs: stat(2) and /proc/pid/maps returns different devices Andrew Vagin
2013-07-05  8:06 ` Andrey Wagin
2013-07-08 21:54 ` David Sterba
2013-07-10 16:31   ` Mark Fasheh
2013-07-10 17:45     ` Mark Fasheh
2013-07-10 22:26       ` David Sterba
2013-07-19 20:51         ` Mark Fasheh
2013-07-31 18:24           ` David Sterba
2013-10-24 10:41           ` Pavel Emelyanov [this message]
2013-07-11 21:25       ` Andrew Vagin

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=5268F958.60004@parallels.com \
    --to=xemul@parallels.com \
    --cc=avagin@gmail.com \
    --cc=chris.mason@fusionio.com \
    --cc=dsterba@suse.cz \
    --cc=kzak@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mfasheh@suse.de \
    --cc=xemul@openvz.org \
    /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.