I have been 'working' with a Debian version for ARM on what is now a defective 'smartbook'.
Now that I am going deeper than I had intended I would like to ask this:

1) Since this (and most all) 'netbook-type' units have some combination of SPI and NAND flash, and
2) the SPI flash is 'generally' considered 'read-only'... holding essential 'images' usually placed in RAM (updated only as necessary), and
3) the NAND flash, while generally considered the 'hard drive' can/will eventually fail from 'overuse',

What would be the best topology for the filesystem, presuming that the NAND flash will hold the 'lions share' of rarely-changed files/data?... or NOT?

As there are plenty of methods for relocating images to various areas/memory the 'how' is not so much a question...

The machine in question has only 128Mb (only... 64K usedtabe LOTS) of which 16Mb has, to this point, been allocated for kernel use...
The NAND flash is currently a 2Gb 'stick' which I intend to swap out with a 4 or 8-gigger once I know the 'repair' will take...

It makes sense to me that /proc could be located in a portion of RAM, unless there are files that need to be kept for resuse THERE as well...
I suspect that some speed advantage would possibly be seen from the 'rearrangement' as well. Perhaps.

Up to the point where I broke it, I had the entire / filesystem in the 'HD' (NAND) as EXT2.
I have no issues with keeping it that way, particularly if the 'drive' substitution works as I expect it to...

Would appreciate input on this as is convenient!

I've an android in my pocket. That uses yaffs, with squashfs images mapped to ram disks and mounted wherever. They seem to have thought this through as well.

Another option is unionfs, which minimises writes. You can put your squashfs image in and go to work, or use a ro system (e.g.iso9660). Unionfs stores only overwrites. If you want to go to town on that, maybe update your squashfs on power down. That should keep you coding for 3 months.

.. and I thought you were just happy to see me!

Thanks for the input. It doesnt really cover the question tho... perhaps I didnt elaborate adequately.
It isnt so much the TYPE of filesystem as the 'layout'... /bin and /dev located here, /proc and /usr located there... that sort of thing...

Most everyone agrees that yaffs2 or something similar is best for NAND altho it likely would add some overhead to the file I/O with the 'smart' work it does...
Doubt it would be worse than Stacker / Doublespace tho!

You're asking us to share out your memory for you?
proc is a door to ram anyhow . It can all be virtual, except probably /home.

Well, since I wouldnt want to be accused of asking others to do my work for me...

Consider this thread closed.

justboo2u,

No one who has read your Journey to Linux-ify a Chinese 'Smartbook' could ever accuse you of asking us to do your work for you. -- Keep up the good work

I see that you have marked this thread "[SOLVED]", which is enough to "close the case", as it were. Formal closure of a thread is reserved for cases of spamming & other serious rule breakage.

Feel free to continue this problem here, if appropriate.

but since I still have the issue of the malformed bootcmd(tm) to contend with, I guess it would be better for my 8-bit brain to work on one thing at a time...







sounds like a book title... dont-it?

Now that I have this Sylvania (that may be 'broken' now...), and it is already setup with mtd-configured NAND, I must reconsider the problem of setting up the NAND to be:
1) an efficient user of space, and
2) reliable...

I'd rather NOT configure any RAM as ramdisk... I intend to continue using X-windows of some form or another on it, and would benefit from ALL the 'real' RAM I have...
Having said that, I CAN and WOULD be willing to occupy the SD/mmc slot with 'extra HD space' once I get the overall system reliably booting without 'external assistance'. (which begs the question of 'can I keep track of where the little SOB is? )

So,

Here we go again!

Just throwing this out here since they have a section for Sylvania Netbooks/oops tablets.

http://www.androidtablets.net/forum/...tablet-brands/

I appreciate it, and I might take a look, but I have developed an aversion to android...
Would rather go full-blown linux-X anyway...

EDIT:
Nah... that looks to be for tablets and this is not one...

Until the JTAG/SPI programmer shows up I will have to work with 'what I have'...

Right now, the 2gb NAND (the same SAMSUNG everybody else has... fer sure) is divided into:

Kernel-NAND........ (mtdblock6) of 0003Mb (since the kernel is compressed and sits around 2.5 things are cool!)
Filesystem-NAND... (mtdblock7) of 0300Mb (unsure yet what to use this for...)
Logo-NAND.......... (mtdblock8) of 0006Mb (considering nearly ALL .BMPs are no more than 1.5 this is wasteful..)
User-NAND.......... (mtdblock9) of 1700Mb (the current designated location of the root '/' filesystem)

Which totals out to only 2009Mb... leaving 39Mb 'open'... presumably for 'fault relocation' (?)

IF the JTAG can do what I want... I intend to reallocate this NAND into:

Kernel-NAND........ (mtdblock6) of 0004Mb (more room for 'expansion'...)
Logo-NAND.......... (mtdblock7) of 0002Mb (more would be wasteful...)
Filesystem-NAND.... (mtdblock8) .... the rest... 2003Mb. (leaving the 'buffer')

For now, mtdblock9 will contain the entire filesystem (at around 60% used right now), and I expect to have it self-bootable on the NAND tonite after work. ** DONE **

I forsee the /USR, /proc, /var (possibly) being moved to their own partition...
Right now I do not believe /home, /media and some others are necessary and could be removed.