On Mon, 14 Feb 2022 at 17:44, Stefan Hajnoczi wrote:
>
> The following changes since commit cc5ce8b8b6be83e5fe3b668dbd061ad97c534e3f:
>
> Merge remote-tracking branch 'remotes/legoater/tags/pull-ppc-20220210' into
> staging (2022-02-13 20:33:28 +)
>
> are available in the Git repository
Right now I can start two daemons listening on same socket /tmp/vhostqemu. Drop
in a pid lock file and use flock so that only one virtiofsd instance can listen
and other fails with error. C version already does it and errors out with error.
"Cannot lock pid file: Resource temporarily
* Sebastian Hasler (sebastian.has...@stuvus.uni-stuttgart.de) wrote:
> With the current implementation, blocking flock can lead to
> deadlock. Thus, it's better to return EOPNOTSUPP if a user attempts
> to perform a blocking flock request.
>
> Signed-off-by: Sebastian Hasler
Queued, apologies
On Tue, Feb 15, 2022 at 07:15:29PM +0100, Greg Kurz wrote:
> Honor the expected behavior of syncfs() to synchronously flush all data
> and metadata to disk on linux systems.
>
> If virtiofsd is started with '-o announce_submounts', the client is
> expected to send a FUSE_SYNCFS request for each
Honor the expected behavior of syncfs() to synchronously flush all data
and metadata to disk on linux systems.
If virtiofsd is started with '-o announce_submounts', the client is
expected to send a FUSE_SYNCFS request for each individual submount.
In this case, we just create a new file
FUSE_SYNCFS allows the client to flush the host page cache.
v6: - drop ! announce_submounts part for now, only the root inode is
synced in this case
v5: - split announce_submounts and ! announce_submounts to separate patches
for easier review (but could be squashed together)
-
On Tue, Feb 15, 2022 at 10:18:03AM +0100, Greg Kurz wrote:
> On Mon, 14 Feb 2022 14:09:47 -0500
> Vivek Goyal wrote:
>
> > On Mon, Feb 14, 2022 at 01:56:08PM -0500, Vivek Goyal wrote:
> > > On Mon, Feb 14, 2022 at 01:27:22PM -0500, Vivek Goyal wrote:
> > > > On Mon, Feb 14, 2022 at 02:58:20PM
Iâm not sure, if I am missing something here, but I am observing the
following issue:
In a directory, owned by another user and a common group with SETGID bit set, I
am not able to create a file or directory. Expected behaviour is, that a new
file or directory is created that is owned by my
On Mon, 14 Feb 2022 14:09:47 -0500
Vivek Goyal wrote:
> On Mon, Feb 14, 2022 at 01:56:08PM -0500, Vivek Goyal wrote:
> > On Mon, Feb 14, 2022 at 01:27:22PM -0500, Vivek Goyal wrote:
> > > On Mon, Feb 14, 2022 at 02:58:20PM +0100, Greg Kurz wrote:
> > > > This adds the missing bits to support
On Mon, 14 Feb 2022 13:27:22 -0500
Vivek Goyal wrote:
> On Mon, Feb 14, 2022 at 02:58:20PM +0100, Greg Kurz wrote:
> > This adds the missing bits to support FUSE_SYNCFS in the case submounts
> > aren't announced to the client.
> >
> > Iterate over all inodes and call syncfs() on the ones marked
10 matches
Mail list logo
