← Back to team overview

maria-developers team mailing list archive

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.