mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Giuseppe Scrivano <gscrivan@redhat.com>,
	Christian Brauner <brauner@kernel.org>
Cc: Amir Goldstein <amir73il@gmail.com>,
	Alexander Larsson <alexl@redhat.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Miklos Szeredi <miklos@szeredi.hu>,
	Yurii Zubrytskyi <zyy@google.com>,
	Eugene Zemtsov <ezemtsov@google.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v2 0/6] Composefs: an opportunistically sharing verified image filesystem
Date: Tue, 17 Jan 2023 22:28:37 +0800	[thread overview]
Message-ID: <74810a5f-3ed3-27f1-caa6-8d3724f1c85e@linux.alibaba.com> (raw)
In-Reply-To: <87fsc9gt7b.fsf@redhat.com>



On 2023/1/17 21:56, Giuseppe Scrivano wrote:
> Christian Brauner <brauner@kernel.org> writes:
> 

...

> 
> We looked at EROFS since it is already upstream but it is quite
> different than what we are doing as Alex already pointed out.
> 

Sigh..  please kindly help me find out what's the difference if
EROFS uses some symlink layout for each regular inode?

Some question for me to ask about this new overlay permission
model once again:

What's the difference between symlink (maybe with some limitations)
and this new overlay model? I'm not sure why symlink permission bits
is ignored (AFAIK)?  I don't think it too further since I don't quite
an experienced one in the unionfs field, but if possible, I'm quite
happy to learn new stuffs as a newbie filesystem developer to gain
more knowledge if it could be some topic at LSF/MM/BPF 2023.

> Sure we could bloat EROFS and add all the new features there, after all
> composefs is quite simple, but I don't see how this is any cleaner than
> having a simple file system that does just one thing.

Also if I have time, I could do a code-truncated EROFS without any
useless features specificly for ostree use cases.  Or I could just
seperate out all of that useless code of Ostree-specific use cases
by using Kconfig.

If you don't want to use EROFS from whatever reason, I'm not oppose
to it (You also could use other in-kernel local filesystem for this
as well).  Except for this new overlay model, I just tried to say
how it works similiar to EROFS.

> 
> On top of what was already said: I wish at some point we can do all of
> this from a user namespace.  That is the main reason for having an easy
> on-disk format for composefs.  This seems much more difficult to achieve
> with EROFS given its complexity.

Why?


[ Gao Xiang: this time I will try my best stop talking about EROFS under
   the Composefs patchset anymore because I'd like to avoid appearing at
   the first time (unless such permission model is never discussed until
   now)...

   No matter in the cover letter it never mentioned EROFS at all. ]

Thanks,
Gao Xiang

  reply	other threads:[~2023-01-17 14:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13 15:33 Alexander Larsson
2023-01-13 15:33 ` [PATCH v2 1/6] fsverity: Export fsverity_get_digest Alexander Larsson
2023-01-13 15:33 ` [PATCH v2 2/6] composefs: Add on-disk layout Alexander Larsson
2023-01-16  1:29   ` Dave Chinner
2023-01-16 11:00     ` Alexander Larsson
2023-01-16 23:06       ` Dave Chinner
2023-01-17 12:11         ` Alexander Larsson
2023-01-18  3:08           ` Dave Chinner
2023-01-13 15:33 ` [PATCH v2 3/6] composefs: Add descriptor parsing code Alexander Larsson
2023-01-13 15:33 ` [PATCH v2 4/6] composefs: Add filesystem implementation Alexander Larsson
2023-01-13 21:55   ` kernel test robot
2023-01-16 22:07   ` Al Viro
2023-01-17 13:29     ` Alexander Larsson
2023-01-13 15:33 ` [PATCH v2 5/6] composefs: Add documentation Alexander Larsson
2023-01-14  3:20   ` Bagas Sanjaya
2023-01-16 12:38     ` Alexander Larsson
2023-01-13 15:33 ` [PATCH v2 6/6] composefs: Add kconfig and build support Alexander Larsson
2023-01-16  4:44 ` [PATCH v2 0/6] Composefs: an opportunistically sharing verified image filesystem Gao Xiang
2023-01-16  9:30   ` Alexander Larsson
2023-01-16 10:19     ` Gao Xiang
2023-01-16 12:33       ` Alexander Larsson
2023-01-16 13:26         ` Gao Xiang
2023-01-16 14:18           ` Giuseppe Scrivano
2023-01-16 15:27           ` Alexander Larsson
2023-01-17  0:12             ` Gao Xiang
2023-01-17  7:05               ` Amir Goldstein
2023-01-17 10:12                 ` Christian Brauner
2023-01-17 10:30                   ` Gao Xiang
2023-01-17 13:56                   ` Giuseppe Scrivano
2023-01-17 14:28                     ` Gao Xiang [this message]
2023-01-17 15:27                     ` Christian Brauner
2023-01-18  0:22                       ` Dave Chinner
2023-01-18  1:27                         ` Gao Xiang
2023-01-20  9:22                   ` Alexander Larsson

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=74810a5f-3ed3-27f1-caa6-8d3724f1c85e@linux.alibaba.com \
    --to=hsiangkao@linux.alibaba.com \
    --cc=alexl@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=ezemtsov@google.com \
    --cc=gscrivan@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=vgoyal@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zyy@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®