On Mon, Apr 16, 2018 at 7:07 PM, Dave Chinner wrote:
> On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
>> Thanks! As I mentioned before, this is useful. I have a follow-up
>> question. Consider the following workload:
>>
>> creat foo
>> link (foo, A/bar)
>> fsync(foo)
>> cra
On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
> Thanks! As I mentioned before, this is useful. I have a follow-up
> question. Consider the following workload:
>
> creat foo
> link (foo, A/bar)
> fsync(foo)
> crash
>
> In this case, after the file system recovers, do we ex
On Mon, Apr 16, 2018 at 12:39 AM, Amir Goldstein wrote:
> On Mon, Apr 16, 2018 at 3:10 AM, Vijay Chidambaram
> wrote:
> [...]
>> Consider the following workload:
>>
>> creat foo
>> link (foo, A/bar)
>> fsync(foo)
>> crash
>>
>> In this case, after the file system recovers, do we expect foo's
On Mon, Apr 16, 2018 at 12:52 AM, Theodore Y. Ts'o wrote:
> On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
>>
>> I don't think this is what the paper's ext3-fast does. All the paper
>> says is if you have a file system where the fsync of a file persisted
>> only data related to
On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
>
> I don't think this is what the paper's ext3-fast does. All the paper
> says is if you have a file system where the fsync of a file persisted
> only data related to that file, it would increase performance.
> ext3-fast is the na
On Mon, Apr 16, 2018 at 3:10 AM, Vijay Chidambaram wrote:
[...]
> Consider the following workload:
>
> creat foo
> link (foo, A/bar)
> fsync(foo)
> crash
>
> In this case, after the file system recovers, do we expect foo's link
> count to be 2 or 1? I would say 2, but POSIX is silent on this,
Hi Ted,
On Sun, Apr 15, 2018 at 9:13 AM, Theodore Y. Ts'o wrote:
> On Sat, Apr 14, 2018 at 08:35:45PM -0500, Vijaychidambaram Velayudhan Pillai
> wrote:
>> I was one of the authors on that paper, and I didn't know until today you
>> didn't like that work :) The paper did *not* suggest we support
On Sat, Apr 14, 2018 at 08:35:45PM -0500, Vijaychidambaram Velayudhan Pillai
wrote:
> I was one of the authors on that paper, and I didn't know until today you
> didn't like that work :) The paper did *not* suggest we support invented
> guarantees without considering the performance impact.
I had
Hi Ted,
On Sat, Apr 14, 2018 at 8:30 PM, Theodore Y. Ts'o wrote:
> When you open "foo", the restulting file descriptor is not associated
> with the symlink. The resulting file descriptor is the exact same
> thing you would get if you had instead called:
>
> fd = open("/tmp/bar/quux", O_C
Hi Ted,
Thanks for the reply.
On Sat, Apr 14, 2018 at 8:17 PM, Theodore Y. Ts'o wrote:
>
> The only thing I would add to Dave's comments is that a lot of these
> formal semantics are de facto, and not de jure. If you take a look at
> POSIX or the Single Unix Specification, they are remarkably s
On Sat, Apr 14, 2018 at 08:13:28PM -0500, Vijay Chidambaram wrote:
>
> We are *not* saying an fsync on a symlink file has to result in any
> action on the original file. We understand the lack of ordering
> constraints here.
The problem is you're not being precise here. The fsync(2) system
call
The only thing I would add to Dave's comments is that a lot of these
formal semantics are de facto, and not de jure. If you take a look at
POSIX or the Single Unix Specification, they are remarkably silent
about how fsync works.
In fact POSIX/SUS doesn't even define "fsync on a directory". In th
Hi Dave,
Thank you for your detailed reply.
I think we still have a misunderstanding. Bear with me, much of this
may seem obvious to you, but not to us and future readers of this
mailing list :)
We are *not* saying an fsync on a symlink file has to result in any
action on the original file. We u
On Fri, Apr 13, 2018 at 10:27:56PM -0500, Vijay Chidambaram wrote:
> Hi Dave,
>
> Thanks for the reply.
>
> I feel like we are not talking about the same thing here.
>
> What we are asking is: if you perform
>
> fsync(symlink)
> crash
>
> can we expect it to see the symlink file in the parent
Hi Dave,
Thanks for the reply.
I feel like we are not talking about the same thing here.
What we are asking is: if you perform
fsync(symlink)
crash
can we expect it to see the symlink file in the parent directory after
a crash given we didn't fsync the parent directory? Amir argues we
can't ex
On Fri, Apr 13, 2018 at 09:39:27AM -0500, Jayashree Mohan wrote:
> Hey Dave,
>
> Thanks for clarifying the crash recovery semantics of strictly
> metadata ordered filesystems. We had a follow-up question in this
> case.
>
> On Fri, Apr 13, 2018 at 8:16 AM, Amir Goldstein wrote:
> > On Fri, Apr 1
Hey Dave,
Thanks for clarifying the crash recovery semantics of strictly
metadata ordered filesystems. We had a follow-up question in this
case.
On Fri, Apr 13, 2018 at 8:16 AM, Amir Goldstein wrote:
> On Fri, Apr 13, 2018 at 3:54 PM, Vijay Chidambaram
> wrote:
>> Hi Amir,
>>
>> Thanks for the
On Fri, Apr 13, 2018 at 08:52:19AM +0300, Amir Goldstein wrote:
> On Thu, Apr 12, 2018 at 8:51 PM, Jayashree Mohan
> wrote:
> > Hi,
> >
> > We came across what seems to be a crash consistency bug on btrfs and
> > f2fs. When we create a symlink for a file and fsync the symlink, on
> > recovery from
On Fri, Apr 13, 2018 at 3:54 PM, Vijay Chidambaram wrote:
> Hi Amir,
>
> Thanks for the reply!
>
> On Fri, Apr 13, 2018 at 12:52 AM, Amir Goldstein wrote:
>>
>> Not a bug.
>>
>> From man 2 fsync:
>>
>> "Calling fsync() does not necessarily ensure that the entry in the
>> directory containing th
Hi Amir,
Thanks for the reply!
On Fri, Apr 13, 2018 at 12:52 AM, Amir Goldstein wrote:
>
> Not a bug.
>
> From man 2 fsync:
>
> "Calling fsync() does not necessarily ensure that the entry in the
> directory containing the file has also reached disk. For that an
> explicit fsync() on a file d
On Thu, Apr 12, 2018 at 8:51 PM, Jayashree Mohan
wrote:
> Hi,
>
> We came across what seems to be a crash consistency bug on btrfs and
> f2fs. When we create a symlink for a file and fsync the symlink, on
> recovery from crash, the fsync-ed file is missing.
>
> You can reproduce this behaviour usi
Hi,
We came across what seems to be a crash consistency bug on btrfs and
f2fs. When we create a symlink for a file and fsync the symlink, on
recovery from crash, the fsync-ed file is missing.
You can reproduce this behaviour using this minimal workload :
1. symlink (foo, bar)
2. open bar
3. fsyn
22 matches
Mail list logo