What is fsync
crazyboyxx said:
What is fsync
Click to expand...
Click to collapse
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)).
Click to expand...
Click to collapse
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.
_that said:
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.
Click to expand...
Click to collapse
Thanks :good:
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?
your_login said:
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?
Click to expand...
Click to collapse
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.
_that said:
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.
Click to expand...
Click to collapse
What about RRs [Random Reboots] ??
alizafar said:
What about RRs [Random Reboots] ??
Click to expand...
Click to collapse
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
_that said:
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.
Click to expand...
Click to collapse
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?
_that said:
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.
Click to expand...
Click to collapse
Long press back kill apps shouldn't be used if dynamic fsync is disabled?
yavu said:
Long press back kill apps shouldn't be used if dynamic fsync is disabled?
Click to expand...
Click to collapse
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.
_that said:
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.
Click to expand...
Click to collapse
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.
sgkla said:
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.
Click to expand...
Click to collapse
Killing an app is exactly as dangerous or safe with fsync disabled as with fsync enabled.
@_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
HassanM said:
@_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???
Click to expand...
Click to collapse
Have you read post #2?
Sent from my ASUS Transformer Pad TF700T using Tapatalk 4
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?
s3icc0 said:
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?
Click to expand...
Click to collapse
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
sbdags said:
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
Click to expand...
Click to collapse
But with enabled I am loosing my data in case of system errors
s3icc0 said:
But with enabled I am loosing my data in case of system errors
Click to expand...
Click to collapse
Yes only if the system crashes you may lose some data.
sbdags said:
Yes only if the system crashes you may lose some data.
Click to expand...
Click to collapse
That is not a good news for someone who spend half of life on XDA trying all possible features, tweaks and roms
_that said:
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.
Click to expand...
Click to collapse
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?