Place Windows page file onto a networked drive.

Soldato
Joined
22 Dec 2008
Posts
10,369
Location
England
This is for XP, though if vista will do so and XP will not then I may change.

I wish to run windows with a paging file, but I do not want the page file to be on the operating system drive. I am assured that a page file is important for stability, although my personal experience does not support this.

So how may I put the paging file onto a networked drive? Google is not very helpful. If I must code this myself so be it, but I am not competent enough to do so at present.

Thank you.
 
Simple enough reason. Windows is running inside virtualbox. The host os and the data files for windows reside on a single ssd. There is an available samsung f1 raid, onto which I would like to place the page file.
The effect would be the same as putting the paging file onto a reasonably quick internal hard drive.
The raid is available to windows as a networked drive, but performs as well as an internal drive normally would.

It's a good point that forcing this might cause more problems than it solves, but I would like to try.
 
I'm sorry guys, I should have provided a lot more information than I did.

I have windows XP running inside a program called virtualbox. This is similar to emulation, as far as XP is concerned it is running on a normal machine with a 1.5ghz celeron processor, 2gb of ram, and a gigabit ethernet card. As far as the host is concerned, there is a 5gb file called XP and a program called virtualbox that is rather demanding of cpu time and ram.

In the same box as the ssd running the host, and containing the 5gb XP file, is a 4 disk raid that I wish to put the page file on. This is formatted as ext2, and behaves like a single drive as far as the host is concerned. A trick of virtualbox is to allow you to map host folders as network drives, so I can map /mnt/raid on the host as R:\ under windows, using the command net use r: \\vboxsvr\raid.

The consequence of this is that XP now believes the raid to be a network attached drive, which fits with the idea of XP not being aware that its running contained within a program. When asked, the file system is VBoxSharedFolderFS, which while better than ext2 is perhaps worse than reporting it as ntfs.

No actual network hardware is involved, so whether bandwidth remains an issue or not is hard to determine. If it is, then the connection is at least at gigabit speeds. I may be able to test the speed of the raid from within the host and from within the guest, but I'll have to learn how to do so first, and I'm not keen on losing the data on the raid to do so.


Asking windows to move the page file as normal fails in that it only lists local drives in the box which you point and click on.

The alternative work around of tell windows that it is a local drive may work, in similar fashion to telling it to treat a usb stick as a removable hard drive. One way of doing this would be to patch virtualbox, but firstly there's not a chance in hell I'm skilled enough to and secondly I suspect there is good reason why the developers have done it this way. While virtualbox is open source and windows is not, I would still prefer vandalising windows.

Finally this is not in any way an attempt at greater performance. This is on the first rig in my signature, so were it performance I was after I would do better to run vista 64 natively. The objective here is stability, there are some people at http://forums.overclockers.co.uk/showthread.php?t=17987573 who strongly disagree with my previous belief that page files are irrelevant, so I'm trying to develop from that.
Id rather the system hang for ages while it writes 2gb of data over a virtual ethernet than have it go down completely to the loss of the work being done on it at the time.

Well if the first post was too brief, and this one too long, perhaps I'll get it right next time. Cheers guys


edit: I don't suppose XP does symlinks does it? Something like make page file, bodily move it without telling windows that I've done so, and put a link in its place
 
Last edited:
I could put it on the ssd at the moment. Two reasons against. The first is that the internet strongly encourages not placing swap onto a solid state disk for lifespan reasons. This is less relevant if the swap is rarely used, but the drives definitely slow down a lot when treated like ram. They do reads very fast, and continuous writes quite fast. But they are shocking at random writes (stutter madly), and I don't want a guest XP having that big an impact on the host system.

Second is the space constraint, there's limits to how much will fit on a 30gb drive. The host system alone is assigned 8gb and this cannot really be decreased. The 22 remaining needs to be split between xp, debian, slackware and probably vista. 2gb is precious :)

The solution of putting fewer things on the ssd has occurred but is not ideal. The drive is occasionally used in different systems (this may prove interesting if XP is trying to use the no longer present network drive as swap).

The various flavours of linux are all quite content using the raid for swap space, only windows is causing trouble here :)
 
It runs solid edge (cad modelling). Solid edge is definitely a tricky thing to run, and could quite easily want more than the 2gb of ram available. You're right in that this has to be done by connecting it as a normal drive rather than by editing windows. A little experimentation with the program has slightly broken windows (it now thinks it has 2gb of swap available on a drive it can no longer see), but on the bright side has lead to a solution.

I have created a new file called swap on the raid. It turns out that virtualbox is able to attach numerous hard drives to a single computer, which I did not realise. I now have a 4gb drive attached under 'my computer' which it appears to be happily treating as a paging file. Tricky to test of course, but I see no reason why this could cause a problem.

Seems so simple in hindsight! Thanks very much for the help here, it would've taken significantly longer without you.
Jon
 
Back
Top Bottom