xfs
[Top] [All Lists]

Re: [PATCH 0/4] xfs: online relabeling [RFC]

To: xfs@xxxxxxxxxxx
Subject: Re: [PATCH 0/4] xfs: online relabeling [RFC]
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 9 Jun 2016 11:51:12 -0500
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <c1922d3d-208c-3699-0a36-26108a4f44de@xxxxxxxxxxx>
References: <c1922d3d-208c-3699-0a36-26108a4f44de@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1

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 ...
> 
> 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.

-Eric

<Prev in Thread] Current Thread [Next in Thread>