What is fsync

Search This thread

_that

Recognized Developer / Inactive RC
Oct 2, 2012
4,821
4,211

It's a system call in Unix/Linux. "man fsync" says:

fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).

So it's something embedded in programs after a related set of write operations to ensure that all data has been written to the storage device. The bolded part is what makes it interesting for some to disable it - "The call blocks" means the calling program waits until it's finished, and this may create lag. The downside is that if the system crashes, the data on the storage devices may be inconsistent, and you may lose data.
 

crazyboyxx

Senior Member
Aug 29, 2009
179
20
It's a system call in Unix/Linux. "man fsync" says:



So it's something embedded in programs after a related set of write operations to ensure that all data has been written to the storage device. The bolded part is what makes it interesting for some to disable it - "The call blocks" means the calling program waits until it's finished, and this may create lag. The downside is that if the system crashes, the data on the storage devices may be inconsistent, and you may lose data.

Thanks :good:
 

your_login

Senior Member
Apr 4, 2011
213
67
What kind of data may be lost when fsync is disabled? could you please give an example? may it cause a serious damage to the phone's system?
 

_that

Recognized Developer / Inactive RC
Oct 2, 2012
4,821
4,211
What kind of data may be lost when fsync is disabled? could you please give an example? may it cause a serious damage to the phone's system?

All data that any app thinks it has written to storage (as it explicitly instructed the OS to do so), but has not been written yet by the OS, may be lost in case of an unexpected system crash.

So as long as the system is running normally, all cached data is eventually written to the eMMC/SD, usually a few seconds after the write request, and everything works normally.

In case of a random reboot, or a "hard" system hang which requires you to power off and restart, or if you run out of battery, AND some app or background service wanted to write something to the file system just before that crash, such cached data is lost.

So what can happen? No hardware is damaged. In the absolutely worst case, the filesystem on your data partition is irrecoverably damaged and you have to do a factory reset, losing all your apps and your data, photos etc. (you do have a backup, don't you?). The chance for this worst case to happen is extremely low - in most cases the filesystem is automatically repaired at startup, and the incompletely written files are simply deleted. If this does not work for some reason, you can still manually try running fsck from the recovery.

If some system service just updated a database before the crash, it may be inconsistent after restarting. This can lead to malfunction of that service, e.g. FCs, missing info in your calendar, missing or garbled media files, etc.

So in summary - as long as the system is stable, disabling fsync only increases performance. By the way, app crashes (FC, ANR, ...) do not hurt here, only complete system crashes are bad.
 

alizafar

Senior Member
Dec 14, 2009
265
27
Saudi Arabia,Al Khober
All data that any app thinks it has written to storage (as it explicitly instructed the OS to do so), but has not been written yet by the OS, may be lost in case of an unexpected system crash.

So as long as the system is running normally, all cached data is eventually written to the eMMC/SD, usually a few seconds after the write request, and everything works normally.

In case of a random reboot, or a "hard" system hang which requires you to power off and restart, or if you run out of battery, AND some app or background service wanted to write something to the file system just before that crash, such cached data is lost.

So what can happen? No hardware is damaged. In the absolutely worst case, the filesystem on your data partition is irrecoverably damaged and you have to do a factory reset, losing all your apps and your data, photos etc. (you do have a backup, don't you?). The chance for this worst case to happen is extremely low - in most cases the filesystem is automatically repaired at startup, and the incompletely written files are simply deleted. If this does not work for some reason, you can still manually try running fsck from the recovery.

If some system service just updated a database before the crash, it may be inconsistent after restarting. This can lead to malfunction of that service, e.g. FCs, missing info in your calendar, missing or garbled media files, etc.

So in summary - as long as the system is stable, disabling fsync only increases performance. By the way, app crashes (FC, ANR, ...) do not hurt here, only complete system crashes are bad.

What about RRs [Random Reboots] ??
 

MartyHulskemper

Senior Member
Jun 5, 2008
1,597
443
What about RRs [Random Reboots] ??
Obviously, the same considerations apply as with a "hard" system hang -- the only difference being that the system reboots itself instead of you pressing the button.

EDIT: I thought it was a strange question (due to the answer being so obvious),, but then I read _that's answer and he even explicitly stated it in his reply. Please read a reply, he didn't formulate so nicely and eloquently to have you read only 4% of what he wrote. :S
 

furou

Senior Member
Jul 29, 2012
76
16
All data that any app thinks it has written to storage (as it explicitly instructed the OS to do so), but has not been written yet by the OS, may be lost in case of an unexpected system crash.

So as long as the system is running normally, all cached data is eventually written to the eMMC/SD, usually a few seconds after the write request, and everything works normally.

In case of a random reboot, or a "hard" system hang which requires you to power off and restart, or if you run out of battery, AND some app or background service wanted to write something to the file system just before that crash, such cached data is lost.

So what can happen? No hardware is damaged. In the absolutely worst case, the filesystem on your data partition is irrecoverably damaged and you have to do a factory reset, losing all your apps and your data, photos etc. (you do have a backup, don't you?). The chance for this worst case to happen is extremely low - in most cases the filesystem is automatically repaired at startup, and the incompletely written files are simply deleted. If this does not work for some reason, you can still manually try running fsck from the recovery.

If some system service just updated a database before the crash, it may be inconsistent after restarting. This can lead to malfunction of that service, e.g. FCs, missing info in your calendar, missing or garbled media files, etc.

So in summary - as long as the system is stable, disabling fsync only increases performance. By the way, app crashes (FC, ANR, ...) do not hurt here, only complete system crashes are bad.

How would having fsync enabled help save data in case of a system crash? I mean, its unexpected and can interrupt the block call verification anyway, no? I'm assuming that without fsync you go for longer without "notifying" the OS about the changes in your data. So is it possible to change the fsync intervals so it doesn't happen constantly and cause lag, but happens frequently enough so that nothing extremely bad happens if the battery runs out or I get a random reboot? Or is that not how it works?
 

yavu

Senior Member
Jan 8, 2013
704
209
All data that any app thinks it has written to storage (as it explicitly instructed the OS to do so), but has not been written yet by the OS, may be lost in case of an unexpected system crash.

So as long as the system is running normally, all cached data is eventually written to the eMMC/SD, usually a few seconds after the write request, and everything works normally.

In case of a random reboot, or a "hard" system hang which requires you to power off and restart, or if you run out of battery, AND some app or background service wanted to write something to the file system just before that crash, such cached data is lost.

So what can happen? No hardware is damaged. In the absolutely worst case, the filesystem on your data partition is irrecoverably damaged and you have to do a factory reset, losing all your apps and your data, photos etc. (you do have a backup, don't you?). The chance for this worst case to happen is extremely low - in most cases the filesystem is automatically repaired at startup, and the incompletely written files are simply deleted. If this does not work for some reason, you can still manually try running fsck from the recovery.

If some system service just updated a database before the crash, it may be inconsistent after restarting. This can lead to malfunction of that service, e.g. FCs, missing info in your calendar, missing or garbled media files, etc.

So in summary - as long as the system is stable, disabling fsync only increases performance. By the way, app crashes (FC, ANR, ...) do not hurt here, only complete system crashes are bad.

Long press back kill apps shouldn't be used if dynamic fsync is disabled?
 

sgkla

Senior Member
Aug 20, 2012
55
16
I don't know what you mean, but I thought I had already made it clear that the only situation where disabled fsync can cause problems is in case of unexpected whole system hangs, shutdowns and reboots.


I think his question is, can he corrupt an app or i's data if he kills it with either a task killer or with a shortcut setup as a task killer. Based on your response, the answer (correct me if I'm wrong) is the only thing that could possibly be affected with a disabled fsync is the app that was killed - which isn't a big deal because it does not fall into your catastrophic loss category of RR, Hard shut, etc. where your system becomes vulnerable.
 

_that

Recognized Developer / Inactive RC
Oct 2, 2012
4,821
4,211
I think his question is, can he corrupt an app or i's data if he kills it with either a task killer or with a shortcut setup as a task killer. Based on your response, the answer (correct me if I'm wrong) is the only thing that could possibly be affected with a disabled fsync is the app that was killed - which isn't a big deal because it does not fall into your catastrophic loss category of RR, Hard shut, etc. where your system becomes vulnerable.

Killing an app is exactly as dangerous or safe with fsync disabled as with fsync enabled.
 

HassanM

Senior Member
Aug 29, 2012
1,599
625
@_that

Can FSync be in any way related to system lag... I mean if it does, will it reduce lag with FSync enabled or disabled???

Thanks

Sent from my GT-I9500 using Tapatalk 4 - Hassan K. Malik
 

s3icc0

Senior Member
Mar 25, 2011
1,947
728
I see what you are trying to say here but unfortunatelly my experiences are different:

With Dynamic FSync Enabled - when my system crashes from any reason I always loose some data (e.g. my tapatalk app always lost all data).
So I keep Dynamic Fsync Disabled - my system can crash anytime and my data are kept intact. ...

So how this really works?
 
  • Like
Reactions: GragonV

sbdags

Inactive Recognized Contributor
Jun 24, 2007
12,753
15,558
Kenilworth, Coventry
OnePlus 9 Pro
I see what you are trying to say here but unfortunatelly my experiences are different:

With Dynamic FSync Enabled - when my system crashes from any reason I always loose some data (e.g. my tapatalk app always lost all data).
So I keep Dynamic Fsync Disabled - my system can crash anytime and my data are kept intact. ...

So how this really works?

If you disabled dynamic fsnc then you have fsync enabled and you are not getting any benefits.

Dynamic FSYNC = ENABLED
- Screen on = NORMAL FSYNC OFF = faster IO
- Screen off = NORMAL FSYNC ON = slower IO

Dynamic FSYNC = DISABLED
- Screen on = NORMAL FSYNC ON = slower IO
- Screen off = NORMAL FSYNC ON = slower IO
 

s3icc0

Senior Member
Mar 25, 2011
1,947
728
If you disabled dynamic fsnc then you have fsync enabled and you are not getting any benefits.

Dynamic FSYNC = ENABLED
- Screen on = NORMAL FSYNC OFF = faster IO
- Screen off = NORMAL FSYNC ON = slower IO

Dynamic FSYNC = DISABLED
- Screen on = NORMAL FSYNC ON = slower IO
- Screen off = NORMAL FSYNC ON = slower IO

But with enabled I am loosing my data in case of system errors :)
 

vinidosantos

New member
Nov 16, 2018
1
0
All data that any app thinks it has written to storage (as it explicitly instructed the OS to do so), but has not been written yet by the OS, may be lost in case of an unexpected system crash.

So as long as the system is running normally, all cached data is eventually written to the eMMC/SD, usually a few seconds after the write request, and everything works normally.

In case of a random reboot, or a "hard" system hang which requires you to power off and restart, or if you run out of battery, AND some app or background service wanted to write something to the file system just before that crash, such cached data is lost.

So what can happen? No hardware is damaged. In the absolutely worst case, the filesystem on your data partition is irrecoverably damaged and you have to do a factory reset, losing all your apps and your data, photos etc. (you do have a backup, don't you?). The chance for this worst case to happen is extremely low - in most cases the filesystem is automatically repaired at startup, and the incompletely written files are simply deleted. If this does not work for some reason, you can still manually try running fsck from the recovery.

If some system service just updated a database before the crash, it may be inconsistent after restarting. This can lead to malfunction of that service, e.g. FCs, missing info in your calendar, missing or garbled media files, etc.

So in summary - as long as the system is stable, disabling fsync only increases performance. By the way, app crashes (FC, ANR, ...) do not hurt here, only complete system crashes are bad.

I got such a huge problem with the force reboot thing and now i'm really thinking it is Fsync related. I own a note 6 pro and i always keep fsync disabled because of the performance increase that people say. One day the phone had to restart the UI and for some reason UI wasn't starting again, so i forced the reboot. The phone ended up with stutters anytime it entered the system and in any rom (even stock), imei and mac got gone and the rom i was on was really buggy, like: status bar wouldn't expand, home button wasn't working and a lot of other things.

This issue happened on the moto g falcon i'm using due to my note 6 pro bug. I also kept Fsync disabled on this one, and i had to forced reboot it because an app had freezed. Again, status bar wasn't expanding, home and recents button wasn't working, notificatons wasn't showing... Thank god my imei and mac isn't gone. A clean rom reflash worked for moto g, but nothing i tried worked out for note 6 pro. It doesn't happens on the first forced reboot, but takes some of them to happen.

Do you think Fsync can have such a deep impact even to mess with some partitions on the phone if it's suddenly rebooted?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 81
    What kind of data may be lost when fsync is disabled? could you please give an example? may it cause a serious damage to the phone's system?

    All data that any app thinks it has written to storage (as it explicitly instructed the OS to do so), but has not been written yet by the OS, may be lost in case of an unexpected system crash.

    So as long as the system is running normally, all cached data is eventually written to the eMMC/SD, usually a few seconds after the write request, and everything works normally.

    In case of a random reboot, or a "hard" system hang which requires you to power off and restart, or if you run out of battery, AND some app or background service wanted to write something to the file system just before that crash, such cached data is lost.

    So what can happen? No hardware is damaged. In the absolutely worst case, the filesystem on your data partition is irrecoverably damaged and you have to do a factory reset, losing all your apps and your data, photos etc. (you do have a backup, don't you?). The chance for this worst case to happen is extremely low - in most cases the filesystem is automatically repaired at startup, and the incompletely written files are simply deleted. If this does not work for some reason, you can still manually try running fsck from the recovery.

    If some system service just updated a database before the crash, it may be inconsistent after restarting. This can lead to malfunction of that service, e.g. FCs, missing info in your calendar, missing or garbled media files, etc.

    So in summary - as long as the system is stable, disabling fsync only increases performance. By the way, app crashes (FC, ANR, ...) do not hurt here, only complete system crashes are bad.
    26

    It's a system call in Unix/Linux. "man fsync" says:

    fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).

    So it's something embedded in programs after a related set of write operations to ensure that all data has been written to the storage device. The bolded part is what makes it interesting for some to disable it - "The call blocks" means the calling program waits until it's finished, and this may create lag. The downside is that if the system crashes, the data on the storage devices may be inconsistent, and you may lose data.
    8
    What about RRs [Random Reboots] ??
    Obviously, the same considerations apply as with a "hard" system hang -- the only difference being that the system reboots itself instead of you pressing the button.

    EDIT: I thought it was a strange question (due to the answer being so obvious),, but then I read _that's answer and he even explicitly stated it in his reply. Please read a reply, he didn't formulate so nicely and eloquently to have you read only 4% of what he wrote. :S
    4
    I think his question is, can he corrupt an app or i's data if he kills it with either a task killer or with a shortcut setup as a task killer. Based on your response, the answer (correct me if I'm wrong) is the only thing that could possibly be affected with a disabled fsync is the app that was killed - which isn't a big deal because it does not fall into your catastrophic loss category of RR, Hard shut, etc. where your system becomes vulnerable.

    Killing an app is exactly as dangerous or safe with fsync disabled as with fsync enabled.
    3
    I see what you are trying to say here but unfortunatelly my experiences are different:

    With Dynamic FSync Enabled - when my system crashes from any reason I always loose some data (e.g. my tapatalk app always lost all data).
    So I keep Dynamic Fsync Disabled - my system can crash anytime and my data are kept intact. ...

    So how this really works?

    If you disabled dynamic fsnc then you have fsync enabled and you are not getting any benefits.

    Dynamic FSYNC = ENABLED
    - Screen on = NORMAL FSYNC OFF = faster IO
    - Screen off = NORMAL FSYNC ON = slower IO

    Dynamic FSYNC = DISABLED
    - Screen on = NORMAL FSYNC ON = slower IO
    - Screen off = NORMAL FSYNC ON = slower IO