All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: [PATCH 0/4] xfs: online relabeling [RFC]
Date: Fri, 10 Jun 2016 09:41:57 -0700	[thread overview]
Message-ID: <20160610164157.GA11810@birch.djwong.org> (raw)
In-Reply-To: <20160610121936.GC21568@bfoster.bfoster>

On Fri, Jun 10, 2016 at 08:19:36AM -0400, Brian Foster wrote:
> On Thu, Jun 09, 2016 at 11:51:12AM -0500, Eric Sandeen wrote:
> > 
> > 
> > On 6/9/16 11:36 AM, Eric Sandeen wrote:
> > > Ok, this more or less works; not really up to snuff
> > > for submission or merging, just sketching it out, but some
> > > questions first:
> > > 
> > > 1) Is there really any point to this? :) We did have one
> > >    request, and btrfs can do it ...
> > > 
> 
> Seems reasonable to me. Any details on the use case for the request?
> 
> > > 2) Is using m_growlock horrible?  growfs is the only other
> > >    thing that writes all supers, so I grabbed it.  We don't
> > >    want multiple relabels stepping on each other.
> > > 
> > > 3) Is there some way to actually force the primary to disk?
> > >    Right now the label change isn't actually visible on the
> > >    primary until unmount, which defeats the purpose.  I'm not
> > >    sure if there's a straightforward/safe way to make it
> > >    visible...
> > 
> 
> > Oh, sorry - I guess it is getting written out, but it's only
> > available via an O_DIRECT read from userspace; it's not
> > invalidating the cache.
> > 
> > # io/xfs_io -c "label derp" /mnt/test
> > label = "derp"
> > 
> > # dd if=/dev/sdb2 bs=512 count=1 | hexdump -C
> > ...
> > 00000060  00 00 0a 00 b4 e5 02 00  02 00 00 08 66 6f 6f 00  |............foo.|
> > ...
> > 
> > # dd if=/dev/sdb2 iflag=direct bs=512 count=1 | hexdump -C
> > ...
> > 00000060  00 00 0a 00 b4 e5 02 00  02 00 00 08 64 65 72 70  |............derp|
> > ...
> > 
> > # dd if=/dev/sdb2 bs=512 count=1 | hexdump -C
> > ...
> > 00000060  00 00 0a 00 b4 e5 02 00  02 00 00 08 66 6f 6f 00  |............foo.|
> > ...
> > 
> > Guess I need to think about this some more.
> > 
> 
> Isn't this to be expected? You're directly accessing the block device of
> a mounted filesystem. I would think this is expected behavior, so long
> as the set/get interfaces through the fs are consistent.

Trouble is, I bet blkid prints LABEL=foo here and not LABEL=derp as
the admin is probably expecting.

/me wonders if invalidate_inode_pages2_range here would help?

--D

> 
> Brian
> 
> > -Eric
> > 
> > _______________________________________________
> > xfs mailing list
> > xfs@oss.sgi.com
> > http://oss.sgi.com/mailman/listinfo/xfs
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2016-06-10 16:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-09 16:36 [PATCH 0/4] xfs: online relabeling [RFC] Eric Sandeen
2016-06-09 16:38 ` [PATCH 1/4] fs: hoist [GS]ET_FSLABEL to vfs Eric Sandeen
2016-06-09 16:39 ` [PATCH 2/4] xfs: factor out secondary superblock updates Eric Sandeen
2016-06-09 16:41 ` [PATCH 3/4] xfs: implement online get/set fs label Eric Sandeen
2016-06-10 12:19   ` Brian Foster
2016-06-09 16:44 ` [PATCH 4/4] xfsprogs: add online relabel commands Eric Sandeen
2016-06-09 16:51 ` [PATCH 0/4] xfs: online relabeling [RFC] Eric Sandeen
2016-06-10 12:19   ` Brian Foster
2016-06-10 16:41     ` Darrick J. Wong [this message]
2016-06-10 18:12       ` Eric Sandeen

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=20160610164157.GA11810@birch.djwong.org \
    --to=darrick.wong@oracle.com \
    --cc=bfoster@redhat.com \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.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.