From: "Richard W.M. Jones" <rjones@redhat.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, Tahsin Erdogan <tahsin@google.com>
Subject: Re: Fast symlinks stored slow
Date: Thu, 13 Jul 2017 18:13:35 +0100 [thread overview]
Message-ID: <20170713171335.GT31999@redhat.com> (raw)
In-Reply-To: <20170713164959.m2hf72b6zqlorn5i@thunk.org>
On Thu, Jul 13, 2017 at 12:49:59PM -0400, Theodore Ts'o wrote:
> On Thu, Jul 13, 2017 at 09:02:13AM +0100, Richard W.M. Jones wrote:
> >
> > From my point of view it's not too much trouble to recreate these
> > filesystems, and we've already proposed a fix for supermin so it
> > creates symlinks properly[1].
>
> My concern is that people using libguestfs, et.al., on Fedura XX and
> then try to decide to upgrade to the 4.13 kernel. So it sounds like
> the exposure could be pretty large. Am I wrong?
In this case we're using libext2fs to build an appliance filesystem,
used to boot a small Linux system which is then run under qemu by
libguestfs. This appliance is completely rebuilt automatically under
many circumstances, for example a host package upgrade (eg. upgrading
the kernel), so it's not a long-lived filesystem that would cause a
problem. Rebuilding only takes a few seconds.
The process is described in more detail here:
http://libguestfs.org/supermin.1.html#SUPERMIN-APPLIANCES
>From our point of view the only issue are some prebuilt appliances
which we have provided to other distributions that cannot / don't want
to use supermin (http://download.libguestfs.org/binaries/appliance/)
and at some point I'm going to have to rebuild these using the fixed
supermin.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
next prev parent reply other threads:[~2017-07-13 17:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-12 17:07 Fast symlinks stored slow Richard W.M. Jones
2017-07-12 20:52 ` Richard W.M. Jones
2017-07-12 21:36 ` Tahsin Erdogan
2017-07-12 23:17 ` Theodore Ts'o
2017-07-13 8:02 ` Richard W.M. Jones
2017-07-13 16:49 ` Theodore Ts'o
2017-07-13 17:13 ` Richard W.M. Jones [this message]
2017-07-13 18:50 ` Theodore Ts'o
2017-07-13 20:27 ` Richard W.M. Jones
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=20170713171335.GT31999@redhat.com \
--to=rjones@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tahsin@google.com \
--cc=tytso@mit.edu \
/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.