Thanks guys. I've enabled that option now. Let's see how it goes. One general question regarding the stability of btrfs in kernel version 4.4. Is this okay for power off test cases? Or are there many important fixes in newer kernels?
On Fri, Aug 4, 2017 at 5:24 PM, Dmitrii Tcvetkov <demfl...@demfloro.ru> wrote: > On Fri, 4 Aug 2017 13:19:39 +0530 > Shyam Prasad N <nspmangal...@gmail.com> wrote: > >> Oh ok. I read this in the man page and assumed that it's on by >> default: flushoncommit, noflushoncommit >> (default: on) >> >> This option forces any data dirtied by a write in a prior >> transaction to commit as part of the current commit. This makes the >> committed state a fully consistent view of the file system from the >> application’s perspective (i.e., it includes all completed >> file system operations). This was previously the behavior only when a >> snapshot was created. >> >> Disabling flushing may improve performance but is not >> crash-safe. >> >> >> Maybe this needs a correction? > > In 4.12 btrfs-progs man pages it's already updated. > > $ man 5 btrfs > ... > flushoncommit, noflushoncommit > (default: off) > > This option forces any data dirtied by a write in a prior > transaction to commit as part of the current commit, > effectively a full filesystem sync. > > This makes the committed state a fully consistent view of > the file system from the application’s perspective (i.e., it > includes all completed file system operations). This was > previously the behavior only when a snapshot was created. > > When off, the filesystem is consistent but buffered writes > may last more than one transaction commit. > > -- -Shyam -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
