Active Topics
 |
|
2009-12-29
, 16:42
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#12
|
Originally Posted by soeiro
Please note that this is NOT about the 256 MiB OneNAND.
However, if we consider the whole partition scheme, N900 seems to be broken by design: sell a 32GB device which very rapidly fills up a 256MB partition (which is already half full) and turns into a brick.
I could start saying that end users won't fill their 256 MiB partition, that optifying packages is very easy, and there's more reasons to why you can't drop Debian .deb packages in the N900, but then this thread would convert into yet another /opt discussion and there's been too many of them already. So please don't, and let the discussion of the ext3 partition keep on.
| The Following User Says Thank You to javispedro For This Useful Post: | ||
|
|
2009-12-29
, 17:11
|
|
Posts: 292 |
Thanked: 131 times |
Joined on Dec 2009
|
#13
|
Originally Posted by javispedro
Sorry. I'm not a Nokia developer. When I saw this thread named "More efficient and flexible use of internal flash" i could only assume that this was the place to discuss improvements in that regard.
Please note that this is NOT about the 256 MiB OneNAND.
I could start saying that end users won't fill their 256 MiB partition, that optifying packages is very easy, and there's more reasons to why you can't drop Debian .deb packages in the N900, but then this thread would convert into yet another /opt discussion and there's been too many of them already. So please don't, and let the discussion of the ext3 partition keep on.
But since you know of those other threads, you could lead a movement to gather them all and talk to a Nokia representative in order to try to improve things for the next generation device ;-)
|
|
2009-12-29
, 22:47
|
|
Posts: 946 |
Thanked: 1,650 times |
Joined on Oct 2009
@ Germany
|
#14
|
Originally Posted by javispedro
I will help all users who don't want to use FAT but not harm FAT users.
Seriously. I don't see how Nokia shipping a larger _ext3_ partition by default will help users who want to use zfs.
No, it doesn't work flawlessly. It's a bit slower.
The sectors are mapped 1:1 and writing is cached on ext3. I don't expect noticable
overhead.
And it's sparse, but not smart. If you full format it/fill it ONCE you'll have a 20GiB FAT image _FOREVER_. You'd have to implement vmware-like shrinking capability, etc. Good luck selling that to the average user.
that it could be done before every mount.
But the average user (you probably mean a less tech-savy user than the average N900 user) would only have a default, non-sparse 27GiB FAT image, anyway.
I though your idea was to create one big ext3 partition only.
|
|
2009-12-29
, 23:29
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#15
|
Originally Posted by titan
Well, they're mapped 1:1, but not linearly or else the file would not be allowed to fragment. So yes, there will be overhead, but I concede the point it may not be noticeable for most use cases since the inode and pointer blocks will be cached.
The sectors are mapped 1:1 and writing is cached on ext3. I don't expect noticable
overhead.
Originally Posted by titan
FINALLY some benefit to the sparse file approach. Feel free to start coding that.SO FAR we have a 27GiB FAT "forever". Finding unallocated FAT sectors is so simple
that it could be done before every mount.
Until such a software is made, I see no benefit to having a sparse FAT32 file over the current dual partition approach.
Last edited by javispedro; 2009-12-29 at 23:33.
|
|
2009-12-29
, 23:35
|
|
Posts: 946 |
Thanked: 1,650 times |
Joined on Oct 2009
@ Germany
|
#16
|
Originally Posted by javispedro
I don't understand your motivation for posting ultra-conservative posts in this thread.
You can very easily do it yourself on the device. I think the ability to still do that and choose whatever filesystem you want is MUCH MORE IMPORTANT than Nokia changing something that works pretty well _right now_.
This a brainstorm thread where some people discuss the pros and cons of possible
solutions to a problem. Not everyone might have that problem but WE do.
It's not up to us whether Nokia will implement one of our solutions in future devices
or even the N900, but here we can try to find with a good solution and suggest it to Nokia
or try to implement it in the community.
Yes, you can do quite a lot with N900 and there many ways to shot yourself into the foot
and brick your device. One of them is repartitioning, which is NOT trivial.
In fact, you can also do a lot things with crippled Android devices or Iphones if you root them. BUT some people bought the N900 hoping to get a real Linux mobile computer out of the box. We don't want to run dangerous hacks just to get something useable.
I am pretty disappointed by the default partitioning scheme and the fact that the standard
applications hardcode the MyDocs FAT partition ($HOME is not visible to them).
I cannot trick them to use files on my large ext3 partition as not even bind or symlinks seem to work in MyDocs.
So the MyDocs partition does NOT work pretty well right now!
I can do most of these now, in the 2GiB ext3 partition and the 256 MiB OneNAND. And if the sizes worry you, you can repartition, which works _better_ than the loop file. And you don't get to confuse users when they ask where their 32 GiB are.
Do you think the 256MB root + 2GB home is not confusing?
Again, what's the difference between a 25GiB MyDocs file in a 27GiB ext3 partition and a 25GiB MyDocs partition with a 2 GiB ext3 partition?
so no change for average joe but many benefits for advanced users.
|
|
2009-12-29
, 23:37
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#17
|
Originally Posted by titan
Please read my ultra-conservative proposed solution then
I don't understand your motivation for posting ultra-conservative posts in this thread.
Originally Posted by titan
This has nothing to do with the partition layout. $HOME has never been visible to the standard applications, even when MyDocs was in the same partition as $HOME.
I am pretty disappointed by the default partitioning scheme and the fact that the standard
applications hardcode the MyDocs FAT partition ($HOME is not visible to them).
If you're really interested in this, you can "move" where applications expect MyDocs. At least, you could in Diablo with the $MYDOCSDIR environment variable.
Originally Posted by titan
So why don't you create the larger ext3 partition into the loop file instead? Unless your plan is to grow it maniacally you "shouldn't" even notice it's running under such a bad performing filesystem.Can you give us ANY evidence why a loop file is bad?
Originally Posted by titan
Not for the average Joe. Or at least -- that was the intention.Do you think the 256MB root + 2GB home is not confusing?
Originally Posted by titan
I consider myself an advanced user and I see no benefit other than the "still not done" dynamic resizing.
For average joe there would be a 27GiB FAT image and 2GB free space on ext3.
so no change for average joe but many benefits for advanced users.
Last edited by javispedro; 2009-12-29 at 23:44.
|
|
2009-12-29
, 23:46
|
|
Posts: 946 |
Thanked: 1,650 times |
Joined on Oct 2009
@ Germany
|
#18
|
Originally Posted by javispedro
I already agreed that for the default configuration a fully allocated FAT image
Until such a software is made, I see no benefit to having a sparse FAT32 file over the current dual partition approach.
would be the simplest and a comparable solution to the current approach.
Advanced users, however, may play with sparse files or whatever they like.
For you, there would be neither an immediate benefit (maybe later?) but also no disadvantages.
If you can find some drawbacks of the approach, I would be happy to discuss
them. but so far you only defend status quo because YOU see no benefits.
So why don't you create the larger ext3 partition into the loop file instead?
Originally Posted by javispedro
yes, that's a separate (reported) bug, but if MyDocs was a ext3 directory I could simply symlink its subdirs to my $HOME subdirs...
This has nothing to do with the partition layout. $HOME has never been visible to the standard applications, even when MyDocs was in the same partition as $HOME.
If you're really interested in this, you can "move" where applications expect MyDocs. At least, you could in Diablo with the $MYDOCSDIR environment variable.
Last edited by titan; 2009-12-29 at 23:56.
|
|
2009-12-29
, 23:58
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#19
|
Originally Posted by titan
Not only I don't see benefits (not even for power users, since those will repartition/remove the FAT32 partition entirely either way) but I see added complexity -- since any modification to the default system scripts would need to handle units with the older layout.
but so far you only defend status quo because YOU see no benefits.
In fact, ANY modification to the currently relatively understood simple system will probably make it harder for people to create their custom layouts, unless it's specifically directed to simplifying it - like for example removing the autogenerated fstab nonsense.
Originally Posted by titan
hildonfm is opensource; you can edit it and name the folders per your liking.
yes, that's a separate (reported) bug, but if MyDocs was a ext3 directory I could simply symlink its subdirs to my $HOME subdirs...
|
|
2009-12-30
, 00:04
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#20
|
(This deserves its own solution entry : ) I've come to like the idea of a user-friendly extras GUI app where you can resize the FAT32 ("user documents & music storage") and ext3 ("application storage") partitions. What do you think?
I agree with you in a very general way: you can make the changes you want yourself. However, as titan has pointed out, there are some standards in generally agreed Linux file system structure that could be improved.
However, if we consider the whole partition scheme, N900 seems to be broken by design: sell a 32GB device which very rapidly fills up a 256MB partition (which is already half full) and turns into a brick.
There must be a reason for having this partition scheme in place, but I'm eager to see something better that could be done to fix it. One idea is to use AUFS or other stackable file system mechanism.
If you follow the optifying threads you will see that even having a tool to help change file locations to /opt is not a complete solution. There are dependencies and lots of other things that make porting a standard Linux package to the N900 a little more difficult.
If we could just grab a standard debian package and install it (or at most recompile it) to N900, without the extra care needed to put files in different places, in no time we would have a wealth of available applications for the N900. With additional time and effort, those applications could be adjusted to the Hildon environment, but at least it would be faster to have them. I know there is easydebian but I'm talking about a speed up in porting applications to the N900 with minimum effort.
Now a question: do you or anybody knows how Nokia is planning to deploy fixes to the base Maemo 5 system? Is it going to be updated deb packages or will we have to reflash the devices?
Last edited by soeiro; 2009-12-29 at 16:34.