maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Brainstorm (https://talk.maemo.org/forumdisplay.php?f=47)
-   -   [Under consideration] More efficient and flexible use of internal flash (https://talk.maemo.org/showthread.php?t=37869)

titan 2009-12-30 12:45

Re: More efficient and flexible use of internal flash
 
Quote:

Originally Posted by aspidites (Post 446099)
What about adding solution #1 as a command line option for the flasher tool? maybe something like "--partition=ext3".

if flasher was open-source it would be nice to able to specify the partition layout.
I'm not sure whether it already generates the partition table or whether it contained in the flash image.

Quote:

Originally Posted by bastler (Post 446489)
1UP! Especially if one could eliminate the "image container" for usb exposure completely and simply expose the home partition directly. I run linux everywhere, I don't need a container for compatibility!

Unfortunately you cannot export a mounted partition. use NFS for that.

javispedro 2009-12-30 13:32

Re: More efficient and flexible use of internal flash
 
I am pretty sure the eMMC image containts the partition layout -- after all, it has changed a few times (the ext3 partition size has increased).

fanoush 2009-12-30 15:39

Re: More efficient and flexible use of internal flash
 
Single partition layout (one big home) may not be ideal when flashing new firmware. Since /home/opt is extension of root file system (most installed 3rd party packages has most bits there) and reflash clears package database I wouldn't be surprised if some initial setup after firmware reflash would do mke2fs on whole home partition to clean leftovers of previous system. Having separate data partition for /home/user/MyDocs might be handy then.

BTW, currently it is not doing it but to me it looks more like bug than intention.

titan 2009-12-30 17:46

Re: More efficient and flexible use of internal flash
 
I disagree. reflash should never touch the eMMC unless the user explicitly asks for it.
/home continains your configuration and other stuff you can't store on a VFAT fs.
/home/opt is simply overwritten when you restore your backup.

Quote:

Originally Posted by fanoush (Post 446739)
Single partition layout (one big home) may not be ideal when flashing new firmware. Since /home/opt is extension of root file system (most installed 3rd party packages has most bits there) and reflash clears package database I wouldn't be surprised if some initial setup after firmware reflash would do mke2fs on whole home partition to clean leftovers of previous system. Having separate data partition for /home/user/MyDocs might be handy then.


mikhmv 2009-12-30 17:54

Re: More efficient and flexible use of internal flash
 
Quote:

Originally Posted by titan (Post 446912)
I disagree. reflash should never touch the eMMC unless the user explicitly asks for it.
/home continains your configuration and other stuff you can't store on a VFAT fs.
/home/opt is simply overwritten when you restore your backup.

I agree: reflash should never touch the eMMC unless the user explicitly asks for it.

aspidites 2009-12-30 18:33

Re: More efficient and flexible use of internal flash
 
Quote:

Originally Posted by mikhmv (Post 446918)
I agree: reflash should never touch the eMMC unless the user explicitly asks for it.

Hence the word command line option. If not specified, it wouldn't be changed.

I guess with the flasher being closed source, my idea would have to be submitted as a feature request to Nokia.

A less elegant solution would be to wrap the script inside another one, applying any necessary changes after the flash has been completed. Not trivial, but possible.

fanoush 2009-12-30 19:34

Re: More efficient and flexible use of internal flash
 
Quote:

Originally Posted by titan (Post 446912)
reflash should never touch the eMMC unless the user explicitly asks for it.

This is true for data (i.e. the FAT partition) but false for /opt (controlled by debian packaging) and IMO also false for user settings. More details explained here

mikhmv 2009-12-30 20:35

Re: More efficient and flexible use of internal flash
 
Quote:

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.
I added:
export MYDOCSDIR="/home/user"
to /etc/profile. Reboot.
It doesn't work. FileManager can see only /home/user/MyDocs and videoplayer too.

titan 2009-12-30 20:40

Re: More efficient and flexible use of internal flash
 
Quote:

Originally Posted by mikhmv (Post 447094)
I added:
export MYDOCSDIR="/home/user"
to /etc/profile. Reboot.
It doesn't work. FileManager can see only /home/user/MyDocs and videoplayer too.

I had tried the same with changing the definition in /etc/osso-af-init/af-defines.sh
to no avail several weeks ago. But IIRC I only checked the camera app.

Graham Cobb 2010-01-02 17:06

Re: More efficient and flexible use of internal flash
 
This is an excellent discussion. In my view, the main issue is not whether users need this repartitioning but whether applications which people develop need it. There may only be small percentage of users who want a large, posix-compatible, never-unmounted, filesystem but there may be some applications those user's want to use which have those requirements (primarily games, probably).

Can we get some agreement on the requirements of the new architecture, before deciding the best way to achieve them?

I agree with Fanoush that we need the system to be able to have part of the MMC which it owns and which can be over-written during upgrades. This could be mounted as /home (or, maybe, something like /home/system).

For those of us who need to be able to boot different software releases, for testing, we would want to have different /home's available, which we arrange to be mounted correctly for the image we are booting (a task for the bootmenu).

There should be a user area (/home/user) which should be common, preserved and not touched by upgrades/reflashes. This area should always be mounted (not unmounted during USB access) and should be a Posix filesystem.

There should also be an area which is exported as a VFAT filesystem over USB for easy transfer of files to/from the device from/to Windows systems. This could be /home/user/MyDocs (although it might be better to have it more explicitly labelled as something like /home/user/My Exported Folder).

The hardest part of the requirement is to work out how the space should be divided up between these three areas. Ideally, of course, they should by dynamic. If anyone can come up with a solution which does that I would be very happy.

Graham


All times are GMT. The time now is 20:59.

vBulletin® Version 3.8.8