All of lore.kernel.org
 help / color / mirror / Atom feed
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 21:27:20 +0100	[thread overview]
Message-ID: <20170713202720.GV31999@redhat.com> (raw)
In-Reply-To: <20170713185037.yz3l6hq3mcc3wppm@thunk.org>

On Thu, Jul 13, 2017 at 02:50:37PM -0400, Theodore Ts'o wrote:
> On Thu, Jul 13, 2017 at 06:13:35PM +0100, Richard W.M. Jones wrote:
> > 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.
> 
> OK, so the risk is if there are other people who are using supermin to
> create appliances.  (One potential use case we might need to
> investigate are services such as SuSE Studio, since it can create
> turnkey VM appliances for its users.)  If these applianes are
> distributed end users (as opposed to being automatically rebuilt as in
> your use case), that's when we would potentially be at risk.

I can't speak about SuSE Studio, but supermin appliances aren't
distributed to end users, but get built on the fly on end user
machines.

I think you may be confusing supermin and libguestfs.  Supermin is a
component we use to make libguestfs work, but it's not how libguestfs
makes new filesystems.

For example if you write:

  $ guestfish -N disk.img=fs:ext4 -m /dev/sda1 touch /foo : ln-s /foo /bar
  $ ll disk.img 
  -rw-rw-r--. 1 rjones rjones 104857600 Jul 13 21:26 disk.img

then the result is a new ext4 filesystem in a disk image, containing a
symlink.  But it was created using the *kernel* + the symlink(2)
system call (not using libext2fs), and in all cases it was in the past
and will be in the future created correctly.

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

      reply	other threads:[~2017-07-13 20:27 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
2017-07-13 18:50         ` Theodore Ts'o
2017-07-13 20:27           ` Richard W.M. Jones [this message]

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=20170713202720.GV31999@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.