[f2fs-dev] f2fs, mount -o sync, sync and cut-off power

[Paolo Minazzi]

I'm Paolo.
I'm integrating f2fs on an ARM board.
I do not have the power-off button.
The normal way to power-off is to cut-off the power.

I tried to mount in sync mode
mount -t f2fs -o sync /dev/mmcblk0 /data
echo Hello > /data/Hello.txt
I realize that if I cut-off the power after "echo" finishes, at the new
boot I see that f2fs execute the recovery that can be also very long.

If I add the "sync" command
mount -t f2fs -o sync /dev/mmcblk0 /data
echo Hello > /data/Hello.txt
sync
I realize that if I cut-off the power after "sync" finishes, at the new
boot I do not see the f2fs
recovery and the boot process is very fast.

This means that -o sync is different that execute a sync command after
each write.
I study deeper the problem reading the source code and I realize that
"sync" produce a checkpoint.
I tried to add the code to make a checkpoint every n writes. It works
but is not a clean solution.
I read and tried ipu-policy but I do not think it is realted to my needs.

Is there a solution to force a checkpoint automatically after each write ?
I need
- not lose data on cut-off
- fast boot (I would like to avoid different mount time)
For me the spped of write is not so important.

I would like avoid the following ...
while true
do
sync
sleep 1
done

Thanks for your time and for this great project
Paolo Minazzi


------------------------------------------------------------------------------

[Changman Lee]

Hi,

When see the manpage of mount, it is written as 'the sync option has
effect only for ext2, ext3, fat, vfat and ufs.' and in case of media
with limited number of write cycles (e.g. some flash drivers) "sync" may
cause life-cycle shortening.

Anyway, you should use O_SYNC when you open a file or call fsync for not
losing your data. Nevertheless this way can not avoid recovery time as well.

Thanks

Post by Paolo Minazzi
I'm Paolo.
I'm integrating f2fs on an ARM board.
I do not have the power-off button.
The normal way to power-off is to cut-off the power.
I tried to mount in sync mode
mount -t f2fs -o sync /dev/mmcblk0 /data
echo Hello > /data/Hello.txt
I realize that if I cut-off the power after "echo" finishes, at the new
boot I see that f2fs execute the recovery that can be also very long.
If I add the "sync" command
mount -t f2fs -o sync /dev/mmcblk0 /data
echo Hello > /data/Hello.txt
sync
I realize that if I cut-off the power after "sync" finishes, at the new
boot I do not see the f2fs
recovery and the boot process is very fast.
This means that -o sync is different that execute a sync command after
each write.
I study deeper the problem reading the source code and I realize that
"sync" produce a checkpoint.
I tried to add the code to make a checkpoint every n writes. It works
but is not a clean solution.
I read and tried ipu-policy but I do not think it is realted to my needs.
Is there a solution to force a checkpoint automatically after each write ?
I need
- not lose data on cut-off
- fast boot (I would like to avoid different mount time)
For me the spped of write is not so important.
I would like avoid the following ...
while true
do
sync
sleep 1
done
Thanks for your time and for this great project
Paolo Minazzi
------------------------------------------------------------------------------
_______________________________________________
Linux-f2fs-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------

[Jaegeuk Kim]

Hi Paolo,

You can use -o sync,fastboot for the case.
Please refer the patch that I sent.

[PATCH 4/4] f2fs: introduce -o fastboot for reducing booting time only

If a system wants to reduce the booting time as a top priority, now we can
use a mount option, -o fastboot.
With this option, f2fs conducts a little bit slow write_checkpoint, but
it can avoid the node page reads during the next mount time.

Note that, from the performance viewpoint, it would be enough to use -o sync,
which has no stability problem since it calls fsync.
But, if you are concerned about booting time rather than sacrificing the
performance, it would be ok to use -o sync,fastboot.

Thanks,

Post by Paolo Minazzi
I'm Paolo.
I'm integrating f2fs on an ARM board.
I do not have the power-off button.
The normal way to power-off is to cut-off the power.
I tried to mount in sync mode
mount -t f2fs -o sync /dev/mmcblk0 /data
echo Hello > /data/Hello.txt
I realize that if I cut-off the power after "echo" finishes, at the new
boot I see that f2fs execute the recovery that can be also very long.
If I add the "sync" command
mount -t f2fs -o sync /dev/mmcblk0 /data
echo Hello > /data/Hello.txt
sync
I realize that if I cut-off the power after "sync" finishes, at the new
boot I do not see the f2fs
recovery and the boot process is very fast.
This means that -o sync is different that execute a sync command after
each write.
I study deeper the problem reading the source code and I realize that
"sync" produce a checkpoint.
I tried to add the code to make a checkpoint every n writes. It works
but is not a clean solution.
I read and tried ipu-policy but I do not think it is realted to my needs.
Is there a solution to force a checkpoint automatically after each write ?
I need
- not lose data on cut-off
- fast boot (I would like to avoid different mount time)
For me the spped of write is not so important.
I would like avoid the following ...
while true
do
sync
sleep 1
done
Thanks for your time and for this great project
Paolo Minazzi
------------------------------------------------------------------------------
_______________________________________________
Linux-f2fs-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------

[Paolo Minazzi]

Post by Jaegeuk Kim
Hi Paolo,
You can use -o sync,fastboot for the case.
Please refer the patch that I sent.
[PATCH 4/4] f2fs: introduce -o fastboot for reducing booting time only
If a system wants to reduce the booting time as a top priority, now we can
use a mount option, -o fastboot.
With this option, f2fs conducts a little bit slow write_checkpoint, but
it can avoid the node page reads during the next mount time.
Note that, from the performance viewpoint, it would be enough to use -o sync,
which has no stability problem since it calls fsync.

Hi Kim, thanks for for answer.
To be precise I use a kernel 3.0.35.
I have found a backport of f2fsby arter 97. The backport should be new
enough.

You have written:

Note that, from the performance viewpoint, it would be enough to use -o sync,
which has no stability problem since it calls fsync.

On this I see different behaviour.
I see that "-o sync" does not call fsync.
I have studied small tests with my version (3.0.35 with a f2fs backport)
and mounting with "-o sync"

===== TEST1=====
touch /mnt/file
cut-off the power
In this case the file is not written. The recovery does not find
/mnt/file. The checkpoint is not created.

===== TEST2 =====
echo > /mnt/file
cut-off the power
In this case the file is written, and the recovery sees the /mnt/file.
The checkpoint is not created.
The data are written by the flush f2fs kernel_thread.

In both test TEST1 and TEST2 the checkpoint is not created. I added a
printk in the function write_checkpoint to
see when it is executed. I added also a printk in the flush f2fs
kernel_thread.

I understand that I do not use the latest version, so it is difficult
for you help me.
I cannot port all the new f2fs in my code.I'm afraid to insert bugs.

So I have tried a simple solution, but I'm not sure if it is correct.

I create a simple kernel_thread

int sync_kernel_thread(void *)
{
while(1)
{
f2fs_freeze(sb);
wait_completion(&comp);
}
}


Every operation that write, create file, create directory ..... and so
on .... activate the thread using
complete(&comp);

So my filesystem is always synced. The boot is fast.

I do not think I will introduce race conditions ... What do you think
about ?

Thanks again,
Paolo


------------------------------------------------------------------------------