FORUMS
Remove All Ads from XDA

What is fsync

179 posts
Thanks Meter: 20
 
By crazyboyxx, Senior Member on 27th October 2012, 09:15 AM
Post Reply Email Thread
27th October 2012, 12:02 PM |#2  
Recognized Developer / Recognized Contributor
Thanks Meter: 4,275
 
Donate to Me
More
Quote:
Originally Posted by crazyboyxx

What is fsync

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

Quote:

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.
The Following 26 Users Say Thank You to _that For This Useful Post: [ View ]
27th October 2012, 09:41 PM |#3  
OP Senior Member
Thanks Meter: 20
 
More
Quote:
Originally Posted by _that

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
The Following 2 Users Say Thank You to crazyboyxx For This Useful Post: [ View ] Gift crazyboyxx Ad-Free
28th October 2012, 03:32 PM |#4  
your_login's Avatar
Senior Member
Thanks Meter: 67
 
More
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?
28th October 2012, 05:58 PM |#5  
Recognized Developer / Recognized Contributor
Thanks Meter: 4,275
 
Donate to Me
More
Quote:
Originally Posted by your_login

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.
The Following 78 Users Say Thank You to _that For This Useful Post: [ View ]
13th March 2013, 09:00 AM |#6  
alizafar's Avatar
Senior Member
Flag Saudi Arabia,Al Khober
Thanks Meter: 27
 
More
Quote:
Originally Posted by _that

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] ??
13th March 2013, 11:04 AM |#7  
MartyHulskemper's Avatar
Senior Member
Thanks Meter: 443
 
More
Quote:
Originally Posted by alizafar

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
The Following 8 Users Say Thank You to MartyHulskemper For This Useful Post: [ View ] Gift MartyHulskemper Ad-Free
8th June 2013, 08:52 AM |#8  
Member
Thanks Meter: 16
 
More
Quote:
Originally Posted by _that

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?
The Following 2 Users Say Thank You to furou For This Useful Post: [ View ] Gift furou Ad-Free
26th July 2013, 11:24 PM |#9  
Senior Member
Thanks Meter: 213
 
More
Quote:
Originally Posted by _that

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?
27th July 2013, 09:45 AM |#10  
Recognized Developer / Recognized Contributor
Thanks Meter: 4,275
 
Donate to Me
More
Quote:
Originally Posted by yavu

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.
The Following 2 Users Say Thank You to _that For This Useful Post: [ View ]
2nd August 2013, 01:22 PM |#11  
Member
Thanks Meter: 16
 
More
Quote:
Originally Posted by _that

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.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes