Active Topics
-
Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 1 day, 10 hrs ago -
Handbook (2)
to Maemo 7 / Leste by teroyk - 2 days, 10 hrs ago - more...
|
2010-02-10
, 12:30
|
|
Posts: 946 |
Thanked: 1,650 times |
Joined on Oct 2009
@ Germany
|
#52
|
Originally Posted by soeiro
The flashing is a blind write-only operation. There is no USB mass storage export for the flasher and therefore no mounting or analysis of the current eMMC state.
What about changing the "flash procedure"? Let everything be in the big partition. The flasher tool could not really <i>flash</i> the whole device. But just replace everything but /home. User files would be preserved...
(correct me, if I'm wrong - the source is not public)
|
|
2010-02-10
, 12:31
|
|
Posts: 53 |
Thanked: 143 times |
Joined on Dec 2009
@ Russia
|
#53
|
Originally Posted by bitziz
No there was no actual performance increase. With original firmware you will not notice anything. The problem with watchdog was when I was mixing up file systems. When I disabled it performance was back to the level of original firmware.
@SR, can you explain to me how to disable the watchdog on the device? you were saying you had considerable performance increase after disabling it?
If you still want to try disabling it you should use flasher with a command:
flasher-3.5 --set-rd-flags=no-omap-wd --set-rd-flags=no-ext-wd --enable-rd-mode
Originally Posted by stefanmohl
No i was not using ram disk. I was mounting internal flash (the one with 256Mb) and ext3 partition on top of it (the 2Gb one from internal mmc or from external card, results were the same, swap on the card does not really slow down the system especially if swappiness is set to the lower setting, right now my system boots from mmc and everything works fast). While creating union both of them were mounted with writable rights.
@sr: I did see your previous post regarding aufs and unionfs. Great work in coming up with those results, even if the results themselves were kind of depressing! One thing I was wondering about though: If I got what you were doing right, you were using a ram disk backed by a flash drive; essentially your ram-disk was a write-through cache backed by the flash.
For the root partition problem, the situation is slightly different - both backing and front store are persistent. In this case, the fast flash stores the clean Nokia distro and the big flash stores all user additions. The big flash is superimposed over the fast flash so that reads see the big flash first, and writes only hit the big flash. This is more of a read-through rather than write-through scenario, if you get what I mean. I also assume that writes to files that already exist in the fast flash (i.e. modifications) go directly to the fast flash, rather than stick in the big flash like normal writes.
Do you think unionfs is so hopeless that there is no point in trying, or do you think you could have a look at how unionfs works in those conditions? Your basic idea is so pure and elegant that I really hope there is a way of saving it!
Does anyone here know anyone working on unionfs? Are there any Nokians here? Could Nokia consider putting in some work on unionfs?
The default behavior for the union is to write all modifications to the file to the most top writable partition that already has the file and to create new files in the most top writable partition that already has the closest folder structure. So generally that would be internal flash as it already has all files. ext3 partition is empty at the first boot.
Aufs has settings to override this behavior. For example it can be set to create all new files on the partition that has most free space. With this settings generally everything is written to the ext3 partition (and the existing files from internal flash are copied up to ext3 partition when they are modified).
I did not find how to change the default priorities in unionfs so most of the files end up in internal flash. I am not saying that it is hopeless. If i could override it so that all write and create operations were on the ext3 partition and only rename operations were in internal flash (as rename is the hardest operation for copy up and anyway it does not require space).
|
|
2010-02-10
, 12:39
|
|
Posts: 946 |
Thanked: 1,650 times |
Joined on Oct 2009
@ Germany
|
#54
|
a reverse "optification" could be another solution:
mount eMMC on /emmc
bind mount top directories in / to /emmc/rootfs/*, e.g., mount /usr to /emmc/rootfs/usr
chroot to /emmc (later done during boot process)
create symlinks to /rootfs/*, e.g., symlink /rootfs/usr/bin/* to /usr/bin
this is basically unionfs for free and works fine:
now, instead of symlinking usr we should exclude some directories
for which only the contents should be symlinked as packages might install new files in those
e.g. usr/{bin,lib,share} etc.
Last edited by titan; 2010-02-10 at 13:22. Reason: example
mount eMMC on /emmc
bind mount top directories in / to /emmc/rootfs/*, e.g., mount /usr to /emmc/rootfs/usr
chroot to /emmc (later done during boot process)
create symlinks to /rootfs/*, e.g., symlink /rootfs/usr/bin/* to /usr/bin
this is basically unionfs for free and works fine:
Code:
mkdir -p /home/nroot/rootfs cd /home/nroot/rootfs mkdir bin boot cdrom dev etc floppy initrd lib media mnt proc root sbin srv sys syspart tmp usr var for f in *; do mount -o bind /$f /home/nroot/rootfs/$f; ln -s rootfs/$f ../$f; done mkdir -p home/user opt mount -o bind /home/opt opt mount -o bind /home/user home/user chroot .
for which only the contents should be symlinked as packages might install new files in those
e.g. usr/{bin,lib,share} etc.
Last edited by titan; 2010-02-10 at 13:22. Reason: example
| The Following 2 Users Say Thank You to titan For This Useful Post: | ||
|
|
2010-02-10
, 14:18
|
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#55
|
Originally Posted by titan
Harddrives have very different performance than flash devices. Benchmarks on harddrives aren't comparable with benchmarks on mmc type flash. Benchmarks on the proper SSDs aren't comparable either.
regarding performance: on a HDD nilfs2 performance was not so great
http://www.phoronix.com/scan.php?pag...s_nilfs2&num=1
My benchmarks http://talk.maemo.org/showthread.php...332#post504332
showed that real fs performance on NAND is not that much better than eMMC:
in the best case (compressed zero data) seq. write was 8 vs. 24 MB/s, seq read
19 vs. 30MB/s but with much higher CPU load for UBIFS.
Sequential read/write is a meaningless measure for anything except single-tasking video use...
The issues with mmc is kinda the same as with first generation SSDs, but worse. While they have sequential read speeds of hundreds of megabytes/s, and the OS boot "test" shows ok results, in real use they made the system "stutter". anandtech.com has an excellent series of articles on it...
|
|
2010-02-10
, 15:09
|
|
Posts: 113 |
Thanked: 30 times |
Joined on Oct 2009
|
#56
|
Originally Posted by soeiro
Exactly.
What about changing the "flash procedure"? Let everything be in the big partition. The flasher tool could not really <i>flash</i> the whole device. But just replace everything but /home. User files would be preserved...
I think that having this absurdity of moving everything to /opt and still being at the edge of filling rootfs is actually "Not. An. Option".
The flasher could zip and move the data to the PC, flash the drive, and then put the data back. Alternatively a SD card could do the same job.
With regards to the speed of SD cards noted earlier, 6 mbps is the minimum for class 6. Standard usage is around 12-15 mbps
|
|
2010-02-10
, 19:40
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#57
|
About eMMC performance -
Did you test it with random R/W? I suspect the reason behind a separate 256MB root flash vs 32GB eMMC is actually in performance of single block writes. If eMMC actual block is 256KB then it would have a big lag after a single block write and it may have a toll on writing of close blocks (not adjacent but close enough).
In other words - modification of small files in the same directory of ext3.
Did you test it with random R/W? I suspect the reason behind a separate 256MB root flash vs 32GB eMMC is actually in performance of single block writes. If eMMC actual block is 256KB then it would have a big lag after a single block write and it may have a toll on writing of close blocks (not adjacent but close enough).
In other words - modification of small files in the same directory of ext3.
|
|
2010-02-10
, 19:58
|
|
Posts: 946 |
Thanked: 1,650 times |
Joined on Oct 2009
@ Germany
|
#58
|
my benchmarks are certainly not representative - if you know some better fs benchmark program let me know. sequential access can at least tell you something about the raw performance of the device.
However, I was surprised that UBIFS/NAND was not dramatically faster than ext3/eMMC
even in best-case scenario for the compressed UBIFS.
Also the CPU usage for UBIFS was 80-100% vs. 10-15% for ext3.
I consider that an important criterium for a mobile device, too.
@shadowjk: of course, HDDs are different, but that it performs so badly even on HDDs is IMHO not a good sign. again, we need more benchmarks...
the seek performance was 1100 vs 3700 on a fresh device but CPU usage was 14% vs 98%
http://talk.maemo.org/showthread.php...332#post504332
not surprising if seeks in a compressed zero-filled file.
Last edited by titan; 2010-02-11 at 07:07. Reason: typo
However, I was surprised that UBIFS/NAND was not dramatically faster than ext3/eMMC
even in best-case scenario for the compressed UBIFS.
Also the CPU usage for UBIFS was 80-100% vs. 10-15% for ext3.
I consider that an important criterium for a mobile device, too.
@shadowjk: of course, HDDs are different, but that it performs so badly even on HDDs is IMHO not a good sign. again, we need more benchmarks...
the seek performance was 1100 vs 3700 on a fresh device but CPU usage was 14% vs 98%
http://talk.maemo.org/showthread.php...332#post504332
not surprising if seeks in a compressed zero-filled file.
Last edited by titan; 2010-02-11 at 07:07. Reason: typo
|
|
2010-02-11
, 01:25
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#59
|
IMHO, the difference in performance 3 times clearly justifies 256MB flash usage.
But I guess that "uncompressed" root can give a better difference, just because decompression takes toll on performance.
However, it requires more strict strategy of file/block allocation on 256MB because of space problem.
But I guess that "uncompressed" root can give a better difference, just because decompression takes toll on performance.
However, it requires more strict strategy of file/block allocation on 256MB because of space problem.
|
|
2010-02-11
, 02:28
|
|
Posts: 172 |
Thanked: 170 times |
Joined on Jan 2010
@ Sweden
|
#60
|
I have rewritten my old, rather messy description of Solution #1 completely, and added an idea at the end of how to bootstrap all this after a reflash:
Solution #1: Place root in the large flash and link speed critical files from the fast flash
Posted on 2010-02-09 01:46 UTC by Stefan Möhl.
Basic idea:
o Have the root directory in a large partition in the big flash instead of in the small fast flash.
o Only files and directories that specifically need speed are placed in the fast flash with symlinks into the large root.
This is basically the same trick as optification, just the other way around. Instead of the fast flash as root, we have the big flash as root. Instead of moving large files and linking, we move speed critical files and link. The main advantage is that the default mode of operations is clean: Just install under the normal root hierarchy without any tricks like moving or linking. Specific files and directories from root may be moved and linked to improve performance if desired.
Optification means that we first install and leave the root files in the fast flash, and then move all packages we install in the future to /opt. With this solution we move just a few specific root files and directories (just those that really need it) to the fast flash, and leave all installed packages in normal locations in the big flash. So by default, we move only a specific and limited number of files, instead of moving all future files that will be installed.
Since packages are now normal, installed in their usual locations, we can now start installing all sorts of packages from the Linux community, as long as the binaries are compiled for the Arm processor. All of Debian, for example, has Arm support by default. We will now also have space to install the standard development environments, so if a package has no support for Arm, we can just install the source package and compile directly on our phones for the Arm processor.
Bootstrapping:
Bootstrapping the configuration after reflash: Since a partition in the big flash can not be reflashed without loosing all the data in the user partition (i.e. camera pics, music, etc), reflashes all have to go to the fast flash. Since we want the root to be in the big flash, we will have to move it there from the fast flash somehow. I suggest we do it the same way as we get root access when installing "rootsh": We "install" a large root partition through the app manager.
The "bigroot" package should be like the "rootsh" package: An officially endorsed and supported power user feature. When installing the package, all files are moved from the fast flash to the 2GB partition in the big flash, except the files that should stay in the fast flash for performance reasons. The bootloader is then modified to boot from the new root location, and the device is rebooted.
The "install bigroot" approach has a few advantages. First of all, it permits a rock solid state after a reflash, since it works just like things do now. Users can be warned and choose for themselves if they want to activate bigroot or not, so the pressure of perfect operation is much lower. Many packages won't be installable without installing bigroot, but packages that cater to casual users can still be optified like before. Bigroot is compatible with optification. Also, if your device bricks and you have to reflash, the old bigroot partition isn't cleared until you re-install bigroot. That allows you to rescue some files and configurations once your system is back up and running, and possibly figure out what went wrong.
The installer trick can also be used for applications by adding "speedification" packages. A "speedification" package for an application will move speed-critical files for that application to the fast flash, leaving links behind in the big flash. Similar to optification (though in the reverse direction), but manually activated or deactivated by the user. This way users get detailed control over which applications get to use the fast flash, and can optimize for their own usage patterns.
Solution #1: Place root in the large flash and link speed critical files from the fast flash
Posted on 2010-02-09 01:46 UTC by Stefan Möhl.
Basic idea:
o Have the root directory in a large partition in the big flash instead of in the small fast flash.
o Only files and directories that specifically need speed are placed in the fast flash with symlinks into the large root.
This is basically the same trick as optification, just the other way around. Instead of the fast flash as root, we have the big flash as root. Instead of moving large files and linking, we move speed critical files and link. The main advantage is that the default mode of operations is clean: Just install under the normal root hierarchy without any tricks like moving or linking. Specific files and directories from root may be moved and linked to improve performance if desired.
Optification means that we first install and leave the root files in the fast flash, and then move all packages we install in the future to /opt. With this solution we move just a few specific root files and directories (just those that really need it) to the fast flash, and leave all installed packages in normal locations in the big flash. So by default, we move only a specific and limited number of files, instead of moving all future files that will be installed.
Since packages are now normal, installed in their usual locations, we can now start installing all sorts of packages from the Linux community, as long as the binaries are compiled for the Arm processor. All of Debian, for example, has Arm support by default. We will now also have space to install the standard development environments, so if a package has no support for Arm, we can just install the source package and compile directly on our phones for the Arm processor.
Bootstrapping:
Bootstrapping the configuration after reflash: Since a partition in the big flash can not be reflashed without loosing all the data in the user partition (i.e. camera pics, music, etc), reflashes all have to go to the fast flash. Since we want the root to be in the big flash, we will have to move it there from the fast flash somehow. I suggest we do it the same way as we get root access when installing "rootsh": We "install" a large root partition through the app manager.
The "bigroot" package should be like the "rootsh" package: An officially endorsed and supported power user feature. When installing the package, all files are moved from the fast flash to the 2GB partition in the big flash, except the files that should stay in the fast flash for performance reasons. The bootloader is then modified to boot from the new root location, and the device is rebooted.
The "install bigroot" approach has a few advantages. First of all, it permits a rock solid state after a reflash, since it works just like things do now. Users can be warned and choose for themselves if they want to activate bigroot or not, so the pressure of perfect operation is much lower. Many packages won't be installable without installing bigroot, but packages that cater to casual users can still be optified like before. Bigroot is compatible with optification. Also, if your device bricks and you have to reflash, the old bigroot partition isn't cleared until you re-install bigroot. That allows you to rescue some files and configurations once your system is back up and running, and possibly figure out what went wrong.
The installer trick can also be used for applications by adding "speedification" packages. A "speedification" package for an application will move speed-critical files for that application to the fast flash, leaving links behind in the big flash. Similar to optification (though in the reverse direction), but manually activated or deactivated by the user. This way users get detailed control over which applications get to use the fast flash, and can optimize for their own usage patterns.
 |
| Tags |
| the opt problem |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
|
All times are GMT. The time now is 21:13.
I think that having this absurdity of moving everything to /opt and still being at the edge of filling rootfs is actually "Not. An. Option".
Help improve N900, vote for:
Information about what the email client is doing
Find applications easily with tags for sub-menus
A better help system
Limit download of emails per connection type (don't fetch attachments)
A better use of internal flash