From: "Theodore Ts'o" <tytso@mit.edu>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: Eric Blake <eblake@redhat.com>,
linux-ext4@vger.kernel.org, libguestfs@redhat.com
Subject: Re: e2fsprogs concurrency questions
Date: Sun, 19 Sep 2021 22:40:38 -0400 [thread overview]
Message-ID: <YUf0plXwP/WZ7YJJ@mit.edu> (raw)
In-Reply-To: <20210919123523.GA15475@redhat.com>
On Sun, Sep 19, 2021 at 01:35:23PM +0100, Richard W.M. Jones wrote:
> Are there structures shared between ext2_fs handles?
Sadly, no.
> I mean, if we had two concurrent threads using different ext2_fs
> handles, but open on the same file, is that going to be a problem?
> (It sounds like it would be, with conflicting access to the block
> allocation bitmap and so on.)
Yes, there's going to be a problem.
If you have two separate ext2fs_fs handles (each opened via a separate
call to ext2fs_open), they will not share any structures, nor is there
any locking for any of the data structures. So that means you could
use a single ext2s_fs handle, and share it across threads --- but you
need to make sure that only one thread is using the handle at a time,
and you can't have two file handles open to the same inode, or read an
inode twice, and then modify one, write it back, and expect the other
inode will magically be updated --- because they won't be.
Fundamentally, libext2fs was not designed for concurrent operation.
I suppose you could use fuse2fs, and then having the clients access
the file system via the FUSE interface. That might be more efficient.
- Ted
prev parent reply other threads:[~2021-09-20 2:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 21:06 e2fsprogs concurrency questions Eric Blake
2021-09-19 3:49 ` Theodore Ts'o
2021-09-19 10:39 ` Andreas Dilger
2021-09-20 16:33 ` Richard W.M. Jones
2021-09-19 12:35 ` Richard W.M. Jones
2021-09-20 2:40 ` Theodore Ts'o [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=YUf0plXwP/WZ7YJJ@mit.edu \
--to=tytso@mit.edu \
--cc=eblake@redhat.com \
--cc=libguestfs@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=rjones@redhat.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;
as well as URLs for NNTP newsgroup(s).