Noatime And Read-only /

[foft]

I have put some scripts on my website at http://www.scrameta.net/noatime.html. They change the start scripts to mount with noatime and also make NAND read-only. This prevents lots of unncessary writes to the flash and should also be safer.

Essentially they add "remount / -o remount,noatime,ro" to the start of profile and add "noatime" to the /mnt/sd mount command at the end of profile. All the scripts do is copy over a pre-modified version of profile from the 1.1.0 firmware. See the README or my site for more details.

As with anything that modifies the NAND, proceed with caution!

 

[green1152]

Will we be able to take it out of read-only mode easily?

 

[foft]

Will we be able to take it out of read-only mode easily?

​

Yes. There is an uninstall script that copies the original profile over.

There is also an unlock script to temporarily do it.

Mark

 

[judge0]

Files used by GPH supplied software: /usr/gp2x/bookmark.dat
/var/log/*
/var/lock/*
/var/spool/*
/var/tmp/*

and so on...

While I think it's commendable that you are trying to increase the NANDs lifespan, I can't help but wonder what additional problems are going to be created.
Being unable to run 'dmesg', for instance, because it's output file is locked, may make troubleshooting system problems a little difficult.

A more eloquent solution may lie in placing a second copy of kernel on SD card, along with appropriate Directory structure, and modifying U-Boot to load that instead of NAND based kernel.

A second option would be to see what HH brings, possibly avoiding NAND use altogether.

The options 'noatime' & 'notail' shouldn't create problems, but to make the NAND 'ro' may be a little much (as well as it only applies to the portion of the NAND released to the kernel by U-Boot)

A few other things to be aware of - the NAND is loaded as 'rw' not in 'fstab'/'mtab' but in U-Boots proprietary mechanism, well before the kernel is ever loaded.
The changes you are proposing may not function as you expect them to.

I have been experimenting with trying to get the boot time down, and trying to get a proper USB driver loaded through the kernel. Any script changes that would affect a 'normal' Linux kernel are pretty useless unless matched in changes to U-Boot configuration as well.

Good luck and keep up the good work

 

[foft]

Files used by GPH supplied software: /usr/gp2x/bookmark.dat
/var/log/*
/var/lock/*
/var/spool/*
/var/tmp/*

and so on...

While I think it's commendable that you are trying to increase the NANDs lifespan, I can't help but wonder what additional problems are going to be created.
Being unable to run 'dmesg', for instance, because it's output file is locked, may make troubleshooting system problems a little difficult.

I think that the problems most users are likely to encounter is some apps that write to the NAND (atari800, Scumm etc.) will no longer function correctly. However, on the whole, they shouldn't be writing there! OK - bookmark.dat may be a problem. As for dmesg, anyone running that probably is capable of knowing how to use mount Anyway to change the profile to remount only with noatime, not read-only simple remove the ",ro" from the first mount command -> "mount -o remount,noatime /".

A nice thing about mounting read-only is it makes me think twice before overwriting my libc again

A more eloquent solution may lie in placing a second copy of kernel on SD card, along with appropriate Directory structure, and modifying U-Boot to load that instead of NAND based kernel.

Would be nice, since the SD is more easily replaced. Still should use noatime though. Unfortunately I don't think you can get into the U-Boot menu on retail units. I could flash the dev U-Boot, but don't want to risk that until I get a JTAG set up.

A second option would be to see what HH brings, possibly avoiding NAND use altogether.

The options 'noatime' & 'notail' shouldn't create problems, but to make the NAND 'ro' may be a little much (as well as it only applies to the portion of the NAND released to the kernel by U-Boot)

A few other things to be aware of - the NAND is loaded as 'rw' not in 'fstab'/'mtab' but in U-Boots proprietary mechanism, well before the kernel is ever loaded.
The changes you are proposing may not function as you expect them to.

I have been experimenting with trying to get the boot time down, and trying to get a proper USB driver loaded through the kernel. Any script changes that would affect a 'normal' Linux kernel are pretty useless unless matched in changes to U-Boot configuration as well.

Good luck and keep up the good work

​

The remount definitely works, since it runs the mount command. i.e. it does not just modify fstab/mtab. It is done too late though really as you say:-(

If you know how to get into U-boot so I can tell the kernel to mount read-only initially please let me know. Looking forward to your fast booting kernel VERY much. I miss the almost instant on of GP32. I guess we'll have that with the HH menus shortly though for the non-Linux stuff.

Thanks.

Mark

edit: Doesn't dmesg use an in memory buffer? If I strace it I don't see it reading anything.

 

[Squidge]

Making the nand read only earlier in the boot sequence seems a bad idea to me. Things may have changed in retail kernels, but ages ago when the SD driver was nothing more than a SD eater, I used the nand to store things, and it got pretty full. On the next reboot, the kernel hanged whilst booting saying it couldn't create some file. I've really no intention of doing it again however to find out the name of the file.

I know "full nand" does not equal "readonly nand", but it may be close enough, and stop someone bricking there 2x in the experiment.

 

[judge0]

Files used by GPH supplied software: /usr/gp2x/bookmark.dat
/var/log/*
/var/lock/*
/var/spool/*
/var/tmp/*

and so on...

While I think it's commendable that you are trying to increase the NANDs lifespan, I can't help but wonder what additional problems are going to be created.
Being unable to run 'dmesg', for instance, because it's output file is locked, may make troubleshooting system problems a little difficult.

I think that the problems most users are likely to encounter is some apps that write to the NAND (atari800, Scumm etc.) will no longer function correctly. However, on the whole, they shouldn't be writing there! OK - bookmark.dat may be a problem. As for dmesg, anyone running that probably is capable of knowing how to use mount Anyway to change the profile to remount only with noatime, not read-only simple remove the ",ro" from the first mount command -> "mount -o remount,noatime /".

A nice thing about mounting read-only is it makes me think twice before overwriting my libc again

A more eloquent solution may lie in placing a second copy of kernel on SD card, along with appropriate Directory structure, and modifying U-Boot to load that instead of NAND based kernel.

Would be nice, since the SD is more easily replaced. Still should use noatime though. Unfortunately I don't think you can get into the U-Boot menu on retail units. I could flash the dev U-Boot, but don't want to risk that until I get a JTAG set up.

A second option would be to see what HH brings, possibly avoiding NAND use altogether.

The options 'noatime' & 'notail' shouldn't create problems, but to make the NAND 'ro' may be a little much (as well as it only applies to the portion of the NAND released to the kernel by U-Boot)

A few other things to be aware of - the NAND is loaded as 'rw' not in 'fstab'/'mtab' but in U-Boots proprietary mechanism, well before the kernel is ever loaded.
The changes you are proposing may not function as you expect them to.

I have been experimenting with trying to get the boot time down, and trying to get a proper USB driver loaded through the kernel. Any script changes that would affect a 'normal' Linux kernel are pretty useless unless matched in changes to U-Boot configuration as well.

Good luck and keep up the good work

​

The remount definitely works, since it runs the mount command. i.e. it does not just modify fstab/mtab. It is done too late though really as you say:-(

If you know how to get into U-boot so I can tell the kernel to mount read-only initially please let me know. Looking forward to your fast booting kernel VERY much. I miss the almost instant on of GP32. I guess we'll have that with the HH menus shortly though for the non-Linux stuff.

Thanks.

Mark

edit: Doesn't dmesg use an in memory buffer? If I strace it I don't see it reading anything.

​

As for a faster booting kernel, my tweak has only shaved approximately one second from boot. And not consistently, either. The vast majority of the 20 seconds of boot time is spent in U-Boot space, setting up and populating the JFFS2 file system. A quick read of the U-Boot Manual and FAQ, indicates the culprit is the JFFS2 filesystem itself. It's the most stable, and fastest to use when set up, as well as allowing for compression inside the file system (saves NAND memory). It's biggest downfall is the time it adds to the boot process.

Recompiling both U-Boot and the kernel to operate on a completely different filesystem, with USB and SD support (as well as LCD screen support - thanks for the info, DJWillis) is WAY out of my league. Especially since we are missing source for U-Boot as GPH used it on the retail units, and portions of the source required to compile the kernel(SD, etc).

For any enterprising individual with more ability/knowledge than myself, there is a development kit available at This site for U-Boot, approximately 300MB. It's called the Embedded Linux Development Lit (ELDK).

Such an individual would probably want to download the source version, as the binary is compiled with GCC 3.3 libs.

Again, I still think the HH crew is headed in the right direction, regardless of my earlier stated views on the subject (crow tastes good, don't it )

 

[foft]

Yolrik just pointed out rc.sysinit to me. This touches masses of stuff before its gets to the profile. Probably best to remount noatime at the start of that.

Mark