Reply
Thread Tools
jcompagner's Avatar
Posts: 290 | Thanked: 165 times | Joined on Sep 2009
#21
Originally Posted by Rob1n View Post
Generally you come out about even on these things - you're losing time & power compressing/decompressing but gaining by reading/writing less data. The compression algorithm is chosen to balance the compression ratio & compression/decompression times.

yes back in the early days, in pc's you could get even better performance with compressing because HD's where really slow compared to the processor.

But with the way flash works.. i dont know if this is really a gain..

For example reading 1KB will result in a read of 1 Page (mostly 4KB)

and writing is especially with not so performing i/o controllers is done in Blocks and those are X number of pages of total sometimes 512KB at total.

So to write a 1KB block 512KB needs to be read in. 1KB updated in that block and then 512KB written again.

But this all depends on what kind of flash controller is in the N900...
But i cant believe that with flash we really gain much in read speed and write speed is really a bit slower..
 
Posts: 946 | Thanked: 1,650 times | Joined on Oct 2009 @ Germany
#22
Note that we have done some benchmarks on the real filesystem performance
for different media and filesystem http://talk.maemo.org/showpost.php?p...2&postcount=76
The NAND results are the best case scenario, as only a highly compressable stream is written.
Real life scenarios may be much worse and are on my todo list.

You can also find my ideas for a "full optification" solution on
http://wiki.maemo.org/User:Tanner#full_optification
 

The Following User Says Thank You to titan For This Useful Post:
GeneralAntilles's Avatar
Posts: 5,478 | Thanked: 5,222 times | Joined on Jan 2006 @ St. Petersburg, FL
#23
Originally Posted by stefanmohl View Post
If Nokia would change the default Maemo5 distribution to have root directory files in the large slow flash by default, and only the files that really need it in the fast flash, then it would be distribution policy. Then it wouldn't break at each upgrade any more.
Like I said, this isn't a workable solution. Then each reflash would require overwriting user data.

Not. An. Option.
__________________
Ryan Abel
 

The Following User Says Thank You to GeneralAntilles For This Useful Post:
Posts: 543 | Thanked: 181 times | Joined on Aug 2009 @ Universe,LocalCluster.MilkyWay.Sol.Earth.Europe.Slovenia.Ljubljana
#24
Originally Posted by twaelti View Post
/opt is the official way to go in the linux world anyway, so stop making a fuss about it.
We developers should stop messing in root (I catch myself falling into that trap again and again, last time with shutter install lirc configs into root even altough /opt works as well :-)

Please pleas lern about the FHS before posting such things.

/opt is there for things that AREN'T packaged by the distribution. And the format is generally:
/opt/$VENDOR and then whatever layout under that.

Here's the relevant link to FHS:
http://www.pathname.com/fhs/pub/fhs-...FTWAREPACKAGES

Some alternate path like /usr/local would probably be a better idea in this case. Or even using unionfs-fuse on top of /usr infact that would be nice. Be always able to just unmount all the modifications.
__________________
For any repos or anything else I might have working on my N900 see:
http://wiki.maemo.org/User:Ruskie
A quick list of what I have in the repos
zsh|xmms2|fcron|gtar|gcoreutils
 
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#25
There is one an effective way to solve this problem. It can be not easy -

put all root (besides boot) into 32GB flash and use fast 256MB space as a cache for disk blocks. Initially it would take some additional time and battery to replicate blocks into new 256MB cache but later it would give a fast access to frequently used data with virtually unlimited space.

It is possible just to extend kernel cache interface to include 256MB into it. But to get the result permanent via next reboot it may requires some additional development in FS.
 

The Following 2 Users Say Thank You to egoshin For This Useful Post:
Posts: 946 | Thanked: 1,650 times | Joined on Oct 2009 @ Germany
#26
no, /opt is for add-on software. Everything not shipped by Nokia (i.e. software from extras or Ovi) could be considered as add-on packages. Packages can be installed under /opt/<PACKAGE> and symlinked to /opt/bin or /opt/maemo/bin.
/usr/local is reversed for local installations, i.e. self compiled programs.

Originally Posted by ruskie View Post
/opt is there for things that AREN'T packaged by the distribution. And the format is generally:
/opt/$VENDOR and then whatever layout under that.
Some alternate path like /usr/local would probably be a better idea in this case.
 
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#27
No desktop GNU/Linux distro follows the FHS to the letter.

(oh, and btw: yet another /opt thread > ).
 

The Following User Says Thank You to javispedro For This Useful Post:
Posts: 172 | Thanked: 170 times | Joined on Jan 2010 @ Sweden
#28
Originally Posted by stefanmohl View Post
Hmmm, do you have any information about why this isn't acceptable for Nokia?
I am sorry GeneralAntilles, I seem to have missed your earlier reply to this. From your latest response:

Originally Posted by GeneralAntilles View Post
Like I said, this isn't a workable solution. Then each reflash would require overwriting user data.

Not. An. Option.
From this, I take it that there are two basic problems:

1) The device needs to be capable of getting to a guaranteed stable functioning state from a reflash
2) The reflash should not delete the user's data in the eMMC

At least those two seem like the reasonable requirements.

Well, that obviously means that the most straight-forward method; just installing root in eMMC directly, will not work. However, this is a brainstorming forum, and finding solutions when the most naive approach fails is the whole point of brainstorming. Let's not get disheartened quite yet!

I think that most agree that optification is not good as a long term solution. As such, we really do need to tackle the issue as soon as we can! Until we have it fixed, we will continue to see newbies getting into trouble such as this (the guy ended up re-flashing his device). I would like to argue that a solution will have to be very convoluted before it is worse than optification, so we do have quite a bit of leeway for ideas.
 
Posts: 53 | Thanked: 143 times | Joined on Dec 2009 @ Russia
#29
I've been experimenting with aufs, unionfs and mini_fo for a while to mount ext3 partition on top of internal memory. All of them have problems.
One common problem was that both of the file system partitions needed to be writable. It is because of the complex algorithm when renaming non empty folder from read only file system (aufs page has a good explanation on that). For example application managed did not work because of this problem. So mini_fo did not work at all.
Aufs is most flexible in configuration. But for some reason with it phone stopped playing video. And the battery did not last long with it (~6-8 hours). And I could not get the file system to umount during shutdown so I had a lot of lost data and sometimes after shutdown phone was unusable.
Unionfs was more stable. I did not have the problems aufs had. But it was impossible to set priorities on where to write new files if there are two writable file systems. Everything was written in root file system as it already contained folders where the files were written. Unionfs has awful documentation. It was not easy to find that it was the default behavior for new files. And I could not find how to change that. So very quickly I ended up with 0 bytes left in root file system.

Right now I moved everything to the card and change the root file system to the card during boot. But I had to enable R&D mode and disable watchdog for it to work. While I was experimenting watchdog was only casing trouble. Right now I am searching for a way to remove it from the system.
With disabled watchdog system boots fine from card and everything works fast. When I moved only /usr to the card without disabling watchdog the system was slow and unusable. And it was impossible to move the whole root to the card with it enabled.
I can upload my modified firmware if someone wants to test it. It will write root file system image to the internal mmc card at the first boot and after that it will be booting from the card.
 

The Following 5 Users Say Thank You to @SR For This Useful Post:
Posts: 172 | Thanked: 170 times | Joined on Jan 2010 @ Sweden
#30
@titan: I was just going to suggest that you add your ideas as a solution, but noticed that you have already done so. Thanks, we need to examine some solutions!

I would also like to concur with javispedro: There are many other discussions about /opt and the FHS around the 'net. Lets keep this discussion to the problem of finding a more robust way of using our two flash drives in the N900, rather than discus how standards should be adhered to or interpreted.
 
Reply

Tags
the opt problem

Thread Tools

 
Forum Jump


All times are GMT. The time now is 12:50.