← 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 04, Vladislav Vaintroub wrote:
> Hi Serg,
> > Hi, Vladislav!
> > 
> > > +        srv_use_atomic_writes = (ibool) innobase_use_atomic_writes;
> > 
> > Is that the typical usage pattern in the innodb code?
> > Because it looks a bit silly to me, why couldn't you create a sysvar
> > directly on srv_use_atomic_writes, why an intermediate
> > innobase_use_atomic_writes variable?
> Yes, this is typical usage pattern in Innodb. Bit weird, I agree.  Every
> innobase_xxx variable has an srv_xxx counterpart.  I have no clue why it is
> so, but I did not want to disturb their existing conventions:)

Ok, good that you and Laurinas have figured that out :)

Not that I understand why bool == ulint, but I'm not suggesting to break
this convention.

> > it'd be nice if you could try os_file_set_atomic_writes() here to
> > see if that works. This function creates and opens quite a few
> > files, you could use one of them to mark it for atomic writes, and
> > if that would fail, you'd disable atomic writes, and wouldn't change
> > innobase_file_flush_method and innobase_use_doublewrite.
> It is tricky to do it before files are opened the first time , without
> moving lot of code around - there is non-trivial parsing of tablespace names
> later on in open_or_create_data_files(), just to figure out directories and
> filenames.

I mean, you can try your function on any other file, not necessarily
on the tablespace. Even on a temporary file, like with

  int fd = mysql_tmpfile("ib");
  if (os_file_set_atomic_writes(fd)) ...

> > Btw, why not to use posix_fallocate whenever it's available?
> > Or, at least, with its own --innodb-use-fallocate option?
> Yes, I guess it (the new option) is a good idea.  I created a followup patch
> that introduces the option
> http://lists.askmonty.org/pipermail/commits/2013-April/004569.html . I set
> default to ON.  What do you think?

There are two related threads:

and the one in internals@ mysql list, starting from

In particular, I noticed this part
  I relied on that fallocate does not need fsync since metadata is
  protected by filesystem journal. But I am not confident whether it is
  true. I'm wondering if this patch may lead InnoDB committing schema to
  not function normally. 

What do you know about it, does one need to sync after posix_fallocate()?
What if the filesystem is not journalling?


Follow ups