|
|
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.13 seconds |
|