|
|
10.3: Move swap to another partition in Panther
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.
---
10.3: Move swap to another partition in Panther
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).
10.3: Move swap to another partition in Panther
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....
Hmm. But as I mentioned, I am not using journaling. And the
I do know that adding an ---
10.3: Move swap to another partition in Panther
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!---
D'oh -- Nevermind -- It's Pretty Clear in your First Post....
Sorry. |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.15 seconds |
|