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)).
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.
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.
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.
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.
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?
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
Can FSync be in any way related to system lag... I mean if it does, will it reduce lag with FSync enabled or disabled???
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
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 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?
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)).
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.
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.
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?