LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Linux can not save changes if power off and then on? (https://www.linuxquestions.org/questions/linux-newbie-8/linux-can-not-save-changes-if-power-off-and-then-on-4175476049/)

henryyao 09-05-2013 10:57 AM
Linux can not save changes if power off and then on?
 
Hi, i'm facing a werid thing in my arm-linux system:

After i do some changes to the linux file, for example, modification to /etc/inittab, chmod +x to xxx.sh, using i2ctools to set RTC values...I can see the changes are taken effect. However, after that, If i power my device off and then power on, some files will return to the original status that were before the changes.

What's more werid is that instead of power off the device, if I reboot the device using shell command, then the changes will remain effective, files will not return to the original status that were before the changes.

smallpond 09-05-2013 11:46 AM
Are you issuing a sync command before powering off so the changed blocks in memory are written to disk?

henryyao 09-05-2013 12:31 PM
I dont know there is such thing as sync.
Thanks a lot for the tip.

I've checked the man sync. It says 'sync' writes any data buffered in memory out to disk. This can include (but is not limited to) modified superblocks, modified inodes, and delayed reads and writes.

But why simple commands such as 'chmod +x' will be treated as a delayed reads and writes? Would it be the problem of my slow CPU and something wrong with the data bus?


Quote:
Originally Posted by smallpond (Post 5022415)
Are you issuing a sync command before powering off so the changed blocks in memory are written to disk?

Doc CPU 09-05-2013 02:54 PM
Hi there,

Quote:
Originally Posted by henryyao (Post 5022459)
I've checked the man sync. It says 'sync' writes any data buffered in memory out to disk. This can include (but is not limited to) modified superblocks, modified inodes, and delayed reads and writes.

But why simple commands such as 'chmod +x' will be treated as a delayed reads and writes? Would it be the problem of my slow CPU and something wrong with the data bus?
the speed and power of your CPU has nothing to do with this. It is very common for modern operating systems (not only Linux) to postpone write operations in order to improve performance. Especially the meta-data stored in the directory is updated very often - just think of the time of last access to a file. It wouldn't be clever to write every such change to disk immediately.

And so most systems just prepare this write operation in a buffer in memory and hold it back for some seconds (or even minutes), while subsequent updates only affect the buffered data in memory. Some time later, when the system is idling, it actually writes the modified data to disk.

So, to make sure every change is actually saved to disk, you either have to wait some time while the system is idle (but you don't know how long actually), or you have to force that by issuing a sync command. A controlled shutdown or restart implicitely does a sync.

[X] Doc CPU

michaelk 09-05-2013 03:35 PM
Can you provide some details on your ARM device? What is its make / model.

henryyao 09-05-2013 08:29 PM
Its a tao3530-OMAP3530 chip.

What's superising me is that i'm using i2cset to set RTC time, and even this is buffered, need to use sync command.


Quote:
Originally Posted by michaelk (Post 5022568)
Can you provide some details on your ARM device? What is its make / model.

jpollard 09-05-2013 09:04 PM
The best way to prevent problems is to shut the system down before removing power.

It doesn't matter HOW many "sync" commands you give... some buffers will not be written. Think about it - there are log file buffers that get updated... using the sync command itself causes a buffer to be updated... after the system call is given...

All sync does is MINIMIZE the damage, it doesn't remove all of it.

Firerat 09-05-2013 10:34 PM
are we certain that /etc/inittab is not in ram?

a simple
Code:
df -h
will confirm

henryyao 09-06-2013 08:06 AM
Very good point.

Quote:
Originally Posted by jpollard (Post 5022725)
The best way to prevent problems is to shut the system down before removing power.

It doesn't matter HOW many "sync" commands you give... some buffers will not be written. Think about it - there are log file buffers that get updated... using the sync command itself causes a buffer to be updated... after the system call is given...

All sync does is MINIMIZE the damage, it doesn't remove all of it.
[COLOR="Silver"]

henryyao 09-06-2013 08:07 AM
---------- Post added 09-06-13 at 09:06 AM ----------

[/COLOR]How to confirm that? I'm having the following output of df -h

root@devkit:~/tests# df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 460.5M 337.7M 118.0M 74% /
none 115.5M 92.0K 115.4M 0% /dev
tmpfs 115.5M 72.0K 115.4M 0% /var/volatile
tmpfs 115.5M 0 115.5M 0% /dev/shm
tmpfs 115.5M 0 115.5M 0% /media/ram
/dev/mmcblk0p1 70.4M 2.9M 67.5M 4% /media/mmcblk0p1
/dev/mmcblk0p2 3.6G 2.2G 1.2G 65% /media/mmcblk0p2
/dev/mmcblk0p2 3.6G 2.2G 1.2G 65% /mnt


Quote:
Originally Posted by Firerat (Post 5022761)
are we certain that /etc/inittab is not in ram?

a simple
Code:
df -h
will confirm

Firerat 09-06-2013 08:38 AM
sorry, I should have posted this extended version first time round

Code:
df -T -h /etc/inittab
but it looks like it is not in ram

I did a little reading on ubi0

http://www.linux-mtd.infradead.org/faq/ubifs.html

looks like sync, and some time is what you need

rm2629 09-06-2013 01:48 PM
Another thing if you're writing application programs would be to fork() a child, have the child perform the file action, wait in the parent for the child to complete. Like this:

Code:
pid_t pid;
int w_status;
char *args[5] = {
    "cp",
    "-f",
    "filename1",
    "filename2"
    NULL
};
char *newenv[] = { NULL };

pid = fork();
if(pid < 0)
{
    // error condition - log as appropriate, you can use errno as well here
}
else if(pid == 0)
{
    // This is the child process, execute your actions
    if(execve("/bin/cp", args, newenv) == -1)
    {
        // Error condition - log
    }
}

// else condition - else no needed, this is the parent
waitpid(pid, &w_status, 0);
This will wait for the copy to be completed. Because the child process has to exit once it is done, it will resolve the file handles with the file system I.e. sync just the new file.

I find it faster than a full file system sync call. Again, for programming practice versus the shell.

Correct shutdowns are helpful. But on things like an ARM, it's likely embedded and therefore can be shut down by someone pulling the battery. Hence in a lot of cases, it's best to protect files as much as you can.

jpollard 09-07-2013 01:44 AM
Waiting for a copy to complete does NOT guarantee that the blocks are on disk. All it means is that the process has completed transferring the buffers to the system.

NOT that the buffers are on disk.

That is why it is faster than a sync system call. It doesn't wait for the buffers to be flushed to disk.
It would be like turning off a printer before the last page has ejected... Sure, it has been printed... but has it been fixed...

Most embedded systems don't have a disk... so there is nothing to flush.


All times are GMT -5. The time now is 05:29 AM.