aufs for Puppy

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#21 Post by sunburnt »

Here's the sequence of commands I used:

sh-3.00# mount -t vfat /dev/hda5 /initrd/mnt/data
sh-3.00# mount -t squashfs -o loop devx_214.sfs /initrd/pup_ro3
sh-3.00# mount-FULL -o remount,append:/initrd/pup_ro3 /
sh-3.00# mount-FULL -o remount,del:/initrd/pup_ro3 /

The cursor returns & freezes, & then everything else does slow crash.
Mounting's no problem it seems, it's weard that unmounting does this.
I didn't use "mount-FULL" for the first 2, but they mounted correctly.

As I said, the mount command does give the correct aufs line for me.
All I could find for testing was: puppy-2.14-seamonkey-fulldrivers.iso

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#22 Post by Nathan F »

It would seem that this might have something to do with memory, at least from what I can tell. I experienced no problems adding or deleting branches on my newer athlon 2200Mhz, with 450MB of ram. Moving over to my kids athlon K6, with @750MB ram, still no problems. Then I shut it down, took out two memory sticks, and rebooted, leaving 256MB in place, and experienced the exact behavior you guys are reporting. I'd say that's a clear sign, unless some other data comes my way.

In any event, it seems that aufs makes it perfectly ok to at least add union branches, but it's risky to remove them. We need a lot more testing, in particular on lower end hardware, but I'd like to proceed under the assumption we could probably make a little program to choose extensions to load, and then just leave them loaded until power down or reboot. Perhaps this could be integrated with a configuration file to control what extensions get loaded at boot time, for added flexibility. It's not perfect obviously, but it's definately better functionality than we had before.

If only we could count on everybody having a ton of ram to work with.

Nathan
Bring on the locusts ...

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#23 Post by kirk »

I replace the mount and umount commands with the FULL versions in the mount.aufs and umount.aufs scripts. (couldn't download the new package). All seems to work well for me. I added and removed serveral branches.

I don't understand how these scripts get called when you use the mount-FULL command.

Is there a way to see the state of the current union? The unionctl --list would show you what branches make up the union, what order they are in, and their permissions.

Besides the man page do you know of some other documentation?

Looks promising!

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#24 Post by kirk »

leaving 256MB in place, and experienced the exact behavior you guys are reporting. I'd say that's a clear sign, unless some other data comes my way.
Since getting the mount/umount FULL thing fixed it seems to work well, but I have 512MB of ram. Wonder if swap file usage could be a problem? Free show no swap being utilized on my system. Tomorrow I'll see if I can try it on my kids computer with 256MB.

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#25 Post by Nathan F »

Like I said, we need more testing on lower end hardware.
Is there a way to see the state of the current union?

Code: Select all

cat /proc/mounts | grep aufs
or possibly

Code: Select all

mount | grep aufs
Using the mount command shows what is in /etc/mtab, but this does not seem to reliably get updated, so reading /proc/mounts is the more reliable method.

As for why and how it is calling the scripts that is something I may have to investigate at the source level. I have theories based on how it is behaving and what is in the scripts, but no hard facts yet. I'm no C programmer but I can usually follow along somewhat.

Thanks guys for your hard work and patience testing this. I can only test on the hardware I have myself, and probably would have missed a few problems without your input.

Nathan
Bring on the locusts ...

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#26 Post by sunburnt »

I'll test & verify this when I get to a PC with at least 512MB of ram.
This is strange, Puppy-1 had no such problem, only applies to Puppy-2.

I'd hoped the boot manager we discussed wouldn't be needed, but in light of this I'll finish it.
And I'll add detection of ram size for possable sfs file swapping if this proves to be correct.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#27 Post by sunburnt »

Bad news on testing, only son's PC has 512MB, & it has Win2K & no floppy.
So no easy way to test the memory thing, but you seem to have verified it.
It's hard to imagine what the connection is... maybe AUFS rather than Puppy2 ?

I posted a testing BootManager GUI in Cutting Edge... & need input on it.

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#28 Post by Nathan F »

Very good, I'll put it on my to do list. I had to go out of town for work though, so I'm backed up now on some other things.

Nathan
Bring on the locusts ...

Post Reply