Re: Inconsistent behavior of fsync in btrfs

2018-04-27 Thread Theodore Y. Ts'o
On Fri, Apr 27, 2018 at 11:33:29AM -0600, Chris Mason wrote: > My goal for the fsync tree log was to make it just do the right thing most > of the time. We mostly got there, thanks to a ton of fixes and test cases > from Filipe. > > fsync(some file) -- all the names for this file will exist,

Re: [RFC v2 3/4] ext4: add verifier check for symlink with append/immutable flags

2018-05-13 Thread Theodore Y. Ts'o
On Fri, May 11, 2018 at 11:12:18PM +0200, Jan Kara wrote: > On Thu 10-05-18 16:13:58, Luis R. Rodriguez wrote: > > The Linux VFS does not allow a way to set append/immuttable > > attributes to symlinks, this is just not possible. If this is > > detected inform the user as the filesystem must be

Re: Inconsistent behavior of fsync in btrfs

2018-04-29 Thread Theodore Y. Ts'o
On Sun, Apr 29, 2018 at 03:55:39PM -0500, Vijay Chidambaram wrote: > In the spirit of clarifying fsync behavior, we have one more case > where we'd like to find out what should be expected. > > Consider this: > > Mkdir A > Creat A/bar > Fsync A/bar > Rename A to B > Fsync B/bar > -- Crash -- >

Re: Symlink not persisted even after fsync

2018-04-14 Thread Theodore Y. Ts'o
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

Re: Symlink not persisted even after fsync

2018-04-15 Thread Theodore Y. Ts'o
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

Re: Symlink not persisted even after fsync

2018-04-15 Thread Theodore Y. Ts'o
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

Re: inline extents

2018-09-20 Thread Theodore Y. Ts'o
On Wed, Sep 19, 2018 at 09:18:16PM -0600, Chris Murphy wrote: > > ext4 has inline data, too, so there's every chance grub will corrupt > > ext4 filesystems with tit's wonderful new feature. I'm not sure if > > the ext4 metadata cksums cover the entire inode and inline data, but > > if they do it's