Page 3 of 5
Posted: Sun 10 Mar 2013, 06:28
by gcmartin
Hi @Mavrothal
Just for the sake of understanding and consistent with this discussion, if you have a 64bit PC and a blank CD/DVD, pull LH64 Mariner and boot it pfix=ram
It wont take you longer than 2 minutes to see the operational aspect of his simple SFS processing at boot time. Copy2RAM is an unnecessary convenience. But, you'll see why.
Here to help
Posted: Sun 10 Mar 2013, 07:11
by R-S-H
Hi mavrothal.
Thanks, this is helpful a lot.
Any hints on this differences?
ZDRV:
ADRV:
RSH
Posted: Sun 10 Mar 2013, 11:33
by 01micko
Hi
hehe.. I just built a POC Slacko, updated 3.8.2 kernel (supporting HFS, btrfs and f2fs) with an A drive only.. works beautifully. I may even upload it, but i want to figure out f2fs.
I also hacked 3builddistro to support the a drive concept, it does nothing more than produce a sane DISTRO_SPECS. An iso with A drive needs to be made manually afterwards. Patch later.
Thanks mavrothal
Posted: Sun 10 Mar 2013, 13:06
by mavrothal
R-S-H wrote:Hi mavrothal.
Thanks, this is helpful a lot.
Any hints on this differences?
ZDRV:
ADRV:
RSH
zlayer is the last one, alayer a middle one.
Do the replacement in
Code: Select all
mount -t aufs -o udba=reval,diropq=w,dirs=${UMNTRW}${UMNTRO0}${ALAYER}${YLAYER}${UMNTRO1}${ZLAYER}${UMNTRO} unionfs /pup_new
and will become clear I believe.
Posted: Sun 10 Mar 2013, 13:08
by mavrothal
01micko wrote:I also hacked 3builddistro to support the a drive concept, it does nothing more than produce a sane DISTRO_SPECS. An iso with A drive needs to be made manually afterwards.
That's a good start but spitting at build time is even better
Posted: Sun 10 Mar 2013, 13:20
by 01micko
mavrothal wrote:01micko wrote:I also hacked 3builddistro to support the a drive concept, it does nothing more than produce a sane DISTRO_SPECS. An iso with A drive needs to be made manually afterwards.
That's a good start but spitting at build time is even better
For sure.. or even renaming a custom sfs to the adrive, more flexible, less prone to error. (Maybe more chance of acceptance upstream
). Baby steps.
Posted: Sun 10 Mar 2013, 16:33
by Q5sys
mavrothal wrote:Q5sys wrote:
Actually LHP64 can load all SFS into ram. You have the option to run them from disk or load to ram.
Never used LH64 so I do not know for a fact.
I just glanced at the code and although I can see COPYEXTRASFS2RAM I can not see how more that one SFS is loaded as UMNTRO.
I probably miss something, but can you actually see RAM usage increasing as much as the SFS size when more than 1 extra SFSs are loaded with the copy2am option? (I know you have the RAM for that test
)
I'll be rebooting my machine again in a few days to add some drives... I'll do a few startup schemes and get you some hard results. From memory... yes I have seen memory usage, but memory isn't always the most accurate thing. Give me some time and I'll get you the info.
Posted: Sun 10 Mar 2013, 20:15
by gcmartin
I knew I had seen this.
This is NOT Jeminah's model. It is one that is in place with LH64. ((I believe it may have been missed/overlooked as it is aimed for his 64bit platforms)
See this pictorial for easy understanding.
It is NOT intended to shift current discussion, rather, to present one working concept.
Hope this helps and provides clarity.
Posted: Sun 10 Mar 2013, 20:43
by R-S-H
gcmartin wrote:It is NOT intended to shift current discussion, rather, to present one working concept.
That's a good point - plus: a little guide or help for the less experienced of us - like me!
Ok.
Back to just a
adrv, but still something is getting wrong. The sfs goes to the adrv, I can see the files and use the applications or whatever is in the sfs. I have loaded up to 39 sfs files using sfs_load 1.9.6 (shinobar) - also can unload.
But: after unloading an sfs I can't mount sfs files or iso files by the usual left-click action.
The same on my second edition, adrv & ddrv, which I do attach here, hoping someone will have a look and find my "bugs"?
Seems it's not clear to me , how to handle the tmpfs dirs and the loopX...
Thanks
Posted: Sun 10 Mar 2013, 21:05
by mavrothal
R-S-H wrote:
Back to just a
adrv, but still something is getting wrong. The sfs goes to the adrv, I can see the files and use the applications or whatever is in the sfs. I have loaded up to 39 sfs files using sfs_load 1.9.6 (shinobar) - also can unload.
But: after unloading an sfs I can't mount sfs files or iso files by the usual left-click action.
The same on my second edition, adrv & ddrv, which I do attach here,
I really have a hard time understanding.
After you mount 39 sfs with sfs_load if you unmount (with sfs_load?) *anyone* of those 39 (not the adrv) then you can not mount sfs with sfs_load or you can not mount them with your "left-click"? But before you unload an SFS the left-click works?
What the left-click calls in your case? filemnt? other?
What the command "filemnt /path/name.sfs" reports?
BTW SFS-load also needs to be
patched so will not unmount a/b/cdrv.
Posted: Sun 10 Mar 2013, 21:16
by R-S-H
Hi mavrothal.
If I'm talking about mounting an sfs, I do mean the single left-click-action, loading an sfs means to me: using sfs_load.
Sorry, but I try my best...
Yes, the left-click works until I do unload an sfs (sfs_load) and, yes, it calls filemnt.
I will try the patch of sfs_load, but could you please have a look into my init script for the z,a,d(drv) and how I did arrange them (increasing its numbers etc. - btw: all needed dirs are in initrd.gz, I can see and use everything, even though I can not mount the iso, sfs with right-click, I can load more sfs files using sfs_load).
Thanks
Posted: Sun 10 Mar 2013, 21:22
by mavrothal
R-S-H wrote:
Yes, the left-click works until I do unload an sfs (sfs_load) and, yes, it calls filemnt.
So what is the "filemnt /path_to_sfs/name.sfs" output when typed in the terminal (after you have unloaded an sfs and left-click fails). ie what is the error? and why do you think that is realated to init? Is this the ONLY change between a working and an non-working version?
Posted: Sun 10 Mar 2013, 21:29
by R-S-H
mavrothal wrote:R-S-H wrote:
Yes, the left-click works until I do unload an sfs (sfs_load) and, yes, it calls filemnt.
So what is the "filemnt /path_to_sfs/name.sfs" output when typed in the terminal (after you have unloaded an sfs and left-click fails). ie what is the error? and why do you think that is realated to init? Is this the ONLY change between a working and an non-working version?
I'm currently using the no-adrv-initrd.gz, so I need to reboot to get the error message from terminal. Will post this later.
Yes, this is the only change, but I'm not sure yet, because of the not yet patched version of sfs_plus...
I will first do these patches, and after this, doing everything again, watching for the resuts...
Posted: Sun 10 Mar 2013, 21:35
by mavrothal
R-S-H wrote:
Yes, this is the only change, but I'm not sure yet, because of the not yet patched version of sfs_plus...
Would be easier then if you post a "diff -ur" between the adrv and the non-adrv initramfs folders.
Also the SFS_load patch is *only* for ydrv.
The latest sfs_load already has a provision for adrv and if you use b/c/d/e-drv must modify the ydrv patch accordingly.
Posted: Sun 10 Mar 2013, 21:57
by R-S-H
Would be easier then if you post a "diff -ur" between the adrv and the non-adrv initramfs folders.
Ok. Here it is!
Posted: Sun 10 Mar 2013, 22:15
by R-S-H
Oh!!!
I have discovered right now, even though I'm using sfs_load 1.9.6, the adrv is not taken under sfs_load's provision for the adrv. This is because of sfs_load uses DISTRO_ADRVSFS, which I don't. I send the sfs for the use with the adrv from boot menu and LazY Puppy DISTRO_SPECS does not have the DISTRO_ADRVSFS.
Could this be a clue/reason for this weird behavior? I do believe so...
Posted: Sun 10 Mar 2013, 23:12
by 01micko
mavrothal
here is a 3builddistro patch that works, manually adding adrive, so any custom adrive can be added, tested working.
it's against commit faca226129. (20130310)
Posted: Mon 11 Mar 2013, 05:11
by mavrothal
01micko wrote:mavrothal
here is a 3builddistro patch that works, manually adding adrive, so any custom adrive can be added, tested working.
it's against commit faca226129. (20130310)
Looks good. Time to start lobbying
Posted: Mon 11 Mar 2013, 05:15
by mavrothal
R-S-H wrote:Could this be a clue/reason for this weird behavior? I do believe so...
There is only one way to find out...
This and running that filemnt command (preferably with a "set -x" in filemnt if problem persists)
Posted: Tue 12 Mar 2013, 02:30
by greengeek
Now that we have adrv, ddrv and zdrv, could you also add c:drv please (to contain all my Windows files). I noticed ever since I first tried puppy that the c:drv has been missing...
