root filesystem-trashing bug in f2fs + mdadm raid1

[StoatWblr]

Description: Ubuntu Xenial Xerus (development branch)
Release: 16.04

f2fs-tools:
  Installed: 1.6.0-2
  Candidate: 1.6.0-2
  Version table:
 *** 1.6.0-2 500
        500 http://gb.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
        100 /var/lib/dpkg/status

100% repeatable on various machines.

How to trigger:

1: Setup mdadm raid1 on 2 sata SSDs

2: Format as f2fs

3: install Wily or Xenial onto the f2fs (to be mounted as / in final system), set mountpoint to "defaults,discard"
.
4: After installation boot up.

5: Reboot via gui or "shutdown -r", no problem.

6: Update / mount options

By default, with "defaults,discard" these are rw,relatime,background_gc=on,discard,user_xattr,acl,inline_data,extent_cache,active_logs=6

add inline_xattr,inline_dentry,flush_merge

Remake initramfs, update grub, etc. Reboot

Once running with the new parameters:

Leave operating for a while, then shutdown via gui or "shutdown -r"

On reboot, the filesystem will be completely trashed. fsck.f2fs is unlikely to recover it.

This does not happen for non-raid f2fs partitions mounted below root.

Presumably this occurs because the FS is not properly flushed before reboot, but it faces the same filesystem trashing issues if the system is reset.

[Lyn Perrine (walterorlin)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We need some more information from you before we can start working on this bug.

I have the question does this happen in flavors of ubuntu other than lubuntu? You do have nice steps to reproduce but having lxpanel be the cause seems unlikely. This could be a deeper problem with mdadm and f2fs and marking it as affecting thouse would make it more likely to be seen by a developer who fixes this problem.