All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: L A Walsh <xfs@tlinx.org>
Cc: Eric Sandeen <sandeen@sandeen.net>,
	linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [ANNOUNCE] xfsprogs v4.20.0 released
Date: Fri, 22 Feb 2019 18:49:36 -0800	[thread overview]
Message-ID: <20190223024936.GV6503@magnolia> (raw)
In-Reply-To: <5C70AC01.3060306@tlinx.org>

On Fri, Feb 22, 2019 at 06:12:17PM -0800, L A Walsh wrote:
> On 2/22/2019 10:33 AM, Eric Sandeen wrote:
> >         - xfs_scrub: move all executables to /usr/sbin (Darrick Wong)
> >   
> ---
>     How does moving executables to /usr/sbin pertain to cleaning
> metadata?

I think we have a misunderstanding here.  "Move all executables" means I
changed where the xfsprogs package puts the binary when installing the
package.  xfs_scrub does not itself move binaries (or any file) around
when it is running.

The reason for changing the packaging is that xfs_scrub depends on
libraries in /usr, so it makes no sense to have xfs_scrub in /sbin.

> What happens if /usr is not mounted or not created and the user is
> running the xfs utils out of /sbin??

If /usr is broken and won't mount, use xfs_repair to make it mountable,
just like we have always done.

xfs_scrub is only meant to be used as a background process on a system
once it has come completely up.  xfs_repair's role has not changed -- it
is still the intended tool to fix filesystems that will not mount or
that cannot be fixed while online.

> For that matter, if the tools are run out of /sbin, are you saying
> xfs_scrub will move them all off of the root partition onto the /usr
> partition?

No.

>     If you are moving the executables, are you also moving all of their
> linked libraries?  It seems if you are wanting safety, moving the libraries
> and executables to the same directory would be prudent, otherwise,
> why move them to to /usr/sbin?
> >         - Merge libxfs from kernel 4.20 
> >   
> What is libxfs being merged with?

Merging bug fixes from the kernel into xfsprogs.

--D

> Thanks!
> 
> 
> 

  reply	other threads:[~2019-02-23  2:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22 18:33 [ANNOUNCE] xfsprogs v4.20.0 released Eric Sandeen
2019-02-23  2:12 ` L A Walsh
2019-02-23  2:49   ` Darrick J. Wong [this message]
2019-02-23 11:01     ` L A Walsh

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=20190223024936.GV6503@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    --cc=xfs@tlinx.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.