Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the '10.3: Move swap to another partition in Panther' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.3: Move swap to another partition in Panther
Authored by: EatingPie on Nov 14, '03 02:10:26AM
I do understand this and know the problem from Jaguar but I don't believe this can occur anymore in Panther with my setup above, a mount as /Volumes/Swap 1 can only occur if mount -vat hfs fails but autodiskmount -va later on (in StartupItems) is successful at mounting the volume.

Yeah I'm pretty sure you're right here. (I don't have my 10.3 computer because it's getting fixed so I can't check this directly.) But this leads to the nagging question: what happens if the directory at your mount point exists, and has stuff in it? Will the "mount -vat hfs" work? With other UNIX variants, mount DOES, but it hides what's there already. That means if you have existing swap files at in the "/Volumes/Swap" *directory* on your root partition, they get hidden by the new "/Volumes/Swap" *Volume* being mounted there. This makes the files in the directory you've mounted over inaccessible, and you can't delete them. So you've got at least 64MB (1 swap file) of wasted disk space on your root that you can never axe.

That's what I *think* might happen, anyway! Like I said, I can't test to see. But *if* this is the case, it still makes the delete section of the rc script necessary.

Okay moving on...

[T]he existing, early mount -vat hfs in /etc/rc has no effect with fstab formatted as in your original hint, whereas it does indeed cause the mount and disk check if explicit /dev/disk* is used. That's what makes all the difference and makes your use of mount_hfs unnecessary.

You're right here... with one little correction. The mount call does not cause the disk check (fsck) to occur. Moreso, if fsck hasn't occured, mount will fail! The /etc/fstab entry -- either of ours -- causes an fsck to occur, but it happens in the "/etc/rc.boot" file. The root file system gets checked by default (if necessary) in "/etc/rc.boot" *and* any filesystem specified in /etc/fstab. I'm betting this also happened in your testing as well. Then, when you hit the "mount -vat hfs" the fsck has been done, and all is well, so the mount occurs. If the fsck had *not* been done, the mount would have actually failed (with journaling off anyway).

And you are also right about my entry for /etc/fstab not working with mount -vat hfs. But, ironically enough, I don't want it to!!!

Let's look at when a *populated* "/Volumes/Swap" *directory* exists -- for example, in case a previous boot's mount failed... and my swap overflow issue does cause it to fail! Here, I want to delete all the unneccessary system-created garbage in that directory, and do so at boot time... before I mount my *real* Swap volume. I don't care wheether the existing "/Volumes/Swap" is a directory that blocks a mount, or simply contains files that get hidden by the "real" Swap volume once it's mount. In either case, I need to delete that bogus "/Volumes/Swap" directory.

In order for me to do so, the *real* "/Volumes/Swap" *Volume* can NOT be mounted (it's hiding those big 'ol swap files that we never use). That's why I added the umount call in my /etc/rc script -- just for this contingency. But it'd be better (performance-wise) if the volume wasn't mounted at all... that way it doesn't have to be unmounted! (Though the performance hit of mount/unmount/mount is probably negligable during the Panther boot process.) Anyway, that's why I don't care if the mount -vat hfs works: I *always* unmount later so I can get to any extant garbage lying around... and then do the *real* mount afterward so VM works all fine and dandy.

Well, I hope I my explanation made sense... it *is* getting late. I still am loathe to excise the code that deletes old "/Volumes/Swap" garbage, even if your code works as advertised. There's a perfect world, then there's Panther... or any other OS for that matter. And when I code, I just like to make sure I've covered all the bases.

---
-Pie


[ Reply to This | # ]

10.3: Move swap to another partition in Panther
Authored by: daniel_steffen on Nov 14, '03 08:11:18AM
But this leads to the nagging question: what happens if the directory at your mount point exists, and has stuff in it? Will the "mount -vat hfs" work?
yes it does; as you mention, it indeed just hides the contents of the directory. If you also want to see the contents of the dir underlying the mountpoint, use a union mount, c.f. man fstab

So you've got at least 64MB (1 swap file) of wasted disk space on your root that you can never axe.
but as long as /Volumes/Swap is empty before you install your changes to /etc/fstab this will never become a problem.
The root file system gets checked by default (if necessary) in "/etc/rc.boot" *and* any filesystem specified in /etc/fstab..
that's what I though too, and what the fsck manpage leads one to believe; unfortunately it's not the case, fsck still ignores /etc/fstab on Panther :-( (it only uses netinfo which is not running yet in /etc/rc.boot of course).

I had not seen the effects of this because the filesystem referenced in my /etc/fstab was journaled, where it doesn't matter that fsck has not been run, as it always mounts cleanly.

Luckily, there is an easy fix to /etc/rc.boot that emulates the advertised behaviour of fsck for non-journaled filesystems, c.f. patch in my new comment above.

I *always* unmount later so I can get to any extant garbage lying around... and then do the *real* mount afterward so VM works all fine and dandy.
as mentioned, I don't think this is necessary, there will never be any unwanted contents in /Volumes/Swap as long as fsck is run as above, because the mount will then always succeed.

If you wanted to clear /Volumes/Swap even so, you'd be better off using a union mount rather than unmounting and remounting the volume.

The overall disadvantage of your method is that you have to put explicit /dev/disk* values into /etc/rc; whereas with my method, the unique place the Swap partition is referenced by device name is in /etc/fstab. This simplifies maintenance.

Note that the usual caveats about referencing partitions via direct device names apply: you're essentially only safe referencing a partition on your boot drive(which will alwyas be /dev/disk0) in this way , partitions on other drives can change their device name depending on e.g. what removable drives are plugged in.

I use the present technique on various machines not for a separate swap partition but for a separate partition containing _all_ user modified files (for backup ease & sharing by different OS boot partitions); in particular /Library/Preferences is symlinked to a dir on that partition; and files in that directory are needed during the startup process before autodiskmount has run (e.g. to setup networking).
If the volume containing my /Library/Preferences were not mounted cleanly in /etc/rc, it would immediately become apparent to me as networking would not work. This has certainly not been the case across many hard reboots & panics, and with the patch above, it now also works for non-journaled filesystems referenced in /etc/fstab.

[ Reply to This | # ]

10.3: Move swap to another partition in Panther
Authored by: EatingPie on Nov 14, '03 12:05:57PM

It is sounding like both methods do the job, and do it right. I will give yours a shot when I get my computer back from Apple (soon... Please!!!)

But in the mean time....

[T]hat's what I though too, and what the fsck manpage leads one to believe; unfortunately it's not the case, fsck still ignores /etc/fstab on Panther :-( (it only uses netinfo which is not running yet in /etc/rc.boot of course).

I had not seen the effects of this because the filesystem referenced in my /etc/fstab was journaled, where it doesn't matter that fsck has not been run, as it always mounts cleanly.

Hmm. But as I mentioned, I am not using journaling. And the fsck is most definitely getting done. Nothing I tried re-mounted the Swap partition after a forced reboot. It was only after I checked the /etc/rc.boot and added the /etc/fstab entry that it worked.

I do know that adding an /etc/fstab entry in Jaguar didn't work... though what version of Jaguar, I can't remember (all probably!). But in Panther, the entry is causing the fsck to get done, and it's behaving during boot exactly as expected.

---
-Pie


[ Reply to This | # ]

10.3: Move swap to another partition in Panther
Authored by: EatingPie on Nov 14, '03 05:03:18PM
The overall disadvantage of your method is that you have to put explicit /dev/disk* values into /etc/rc; whereas with my method, the unique place the Swap partition is referenced by device name is in /etc/fstab. This simplifies maintenance.

Agreed! I would be happy for a simpler method... though even with your given arguments, I am still loate to eliminate the code the extricates errant swap files on the root volume....

That said, can you please post a full explanation of your solution. IE, what files to change, and exactly how. I have a good idea from your posts already, but something explicit would be handy.

TIA!

---
-Pie


[ Reply to This | # ]

D'oh -- Nevermind -- It's Pretty Clear in your First Post....
Authored by: EatingPie on Nov 14, '03 05:05:26PM

Sorry.

---
-Pie
<http://www.storybytes.com>



[ Reply to This | # ]