[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    Re: [fuse-devel] How to handle lowlevel setattr failing partially?
From:       Nikolaus Rath <Nikolaus () rath ! org>
Date:       2019-01-22 20:14:46
Message-ID: 87y37c8n61.fsf () vostro ! rath ! org
[Download RAW message or body]

On Jan 22 2019, Fabian Vogt <fabian@ritter-vogt.de> wrote:
> Hi,
>
> If writeback caching is enabled, the kernel sends a single setattr request with
> FUSE_SET_ATTR_MTIME | FUSE_SET_ATTR_MTIME_NOW | FUSE_SET_ATTR_ATIME
> | FUSE_SET_ATTR_ATIME_NOW | FUSE_SET_ATTR_CTIME | FUSE_SET_ATTR_SIZE for
> truncation.
>
> If one of those operations fails, e.g. mtime changing fails after truncating
> the file, fuse_reply_err is called, which does not update the file's st_size in
> the kernel cache.
>
> I think libfuse's own fuse_lib_setattr hits the same issue.
>
> In my filesystem implementation I'm doing all of the operations async (and in
> no specific order) and to deal with this I'm doing effectively
>
> fuse_reply_err(req, EIO);
> // Some part of the operation might've succeeded though, inform the kernel
> // about that
> fuse_lowlevel_notify_inval_entry(...);
>
> which I don't think is the correct/best way to handle it and might even lead to
> a deadlock.
>
> Is the filesystem supposed to do this operation atomically, i.e. if changing
> the size fails, revert the time changes?

I think that's the only fully correct way to solve this. I realize this
isn't optimal.

> This wouldn't work at least in this
> case as if the truncation fails, the mtime might still have changed and undoing
> a truncation isn't possible.

Yeah, it's a catch 22.

Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

              »Time flies like an arrow, fruit flies like a Banana. «


-- 
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel

[prev in list] [next in list] [prev in thread] [next in thread]