maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #05322
Re: Rev 3712: MDEV-4338 : Support atomic option on directFS/FusionIO
Hi, Vladislav!
On Apr 05, Vladislav Vaintroub wrote:
>
> > > > it'd be nice if you could try os_file_set_atomic_writes() here
> > > > to see if that works.
> >
> > I mean, you can try your function on any other file, not necessarily
> > on the tablespace. Even on a temporary file
>
> Right, but the subtlety here is that test file needs to be on the same
> device as ibdata1 tablespace, and figuring out the correct directory is not
> trivial .
>
> Apart from easy default situation, where ibdata lands in the into datadir,
> there is innodb_data_home_dir , as well as innodb_data_file_path (this one
> needs to be parsed). Not to forget possible symbolic links . Imagine ibdata1
> is placed on atomic-capable filesystem, and symlink to it into datadir.
>
> So I'd still say this is tricky..
Okay, let's do it your way. If it will cause problems for users we can
always reconsider.
> > What do you know about it, does one need to sync after
> > posix_fallocate()?
>
> This is a good question, and I do not think I have enough knowledge
> to answer that one :)
>
> note, that fsync() is done anyway almost everywhere after
> os_set_file_size()
> 1. os_set_file_size during creation single tablespace (file-per-table I
> believe) is followed almost immediately by os_file_flush()
> 2. os_set_file_size when tablespace is extended, is followed by
> fil_flush.
>
> When innodb starts up for the first time (bootstrap), it is a little
> bit different - log file or tablespace are created ,
> os_set_file_size() is called, and then the file is closed, but not
> flushed. My feeling is that it is ok, hoping at least on close() the
> metadata will be flushed. And even if not, in case of the probably
> worst scenario that machine crashes during bootstrap, - in this case
> user data is not lost , as there is no user data yet.
Right, and as soon as there are any data there - on any transaction -
there will be a flush.
> Having said all this, I would not mind to adding an extra fsync() to
> the function, if this makes feel safer for someone. I think the
> overhead of it would be minimal.
No, I think it's fine the way it is. As you didn't remove any fsyncs and
InnoDB does sync after resizing, it should be ok.
Regards,
Sergei
References