[ros-dev] A reimplementation of reactos' cache manager supporting alternate filesystems better (including ext2)

[Love Nystrom]

On Fri, Nov 13, 2009 at 10:50 PM, Steven Edwards <winehacker at gmail.com>wrote:

> On Thu, Nov 12, 2009 at 8:32 PM, Steven Edwards <winehacker at gmail.com>
> wrote:
> > On Thu, Nov 12, 2009 at 8:29 PM, Steven Edwards <winehacker at gmail.com>
> wrote:
> >> On Thu, Nov 12, 2009 at 11:46 AM, Alex Ionescu <ionucu at videotron.ca>
> wrote:
> >>> 1) You would get the SAME ADVANTAGE by having the FILE on another
> >>> physical drive!
> >>
> >> Wouldn't you still have a problem with fragmentation leading to
> >> additional io? I ask because the VMware/Netapp best practices for
> >> Windows and Linux on ESX clusters still recommends a separate
> >> filesystem dedicated to swap regardless of the the underlying backend
> >> be it block (iSCSI, Fiberchannel) or file (NFS).
>
...
>
> Sorry if the point of the question is not clear. In a RAID/NAS/SAN
> > backend situation, ALL DRIVES are in effect the same PHYSICAL DRIVE so
> > that's why I ask why one would still be recommended to have a separate
> > filesystem.
>
> Ping? Nobody? So no idea why a separate dedicate virtual drive is
> recommended for the pagefile.sys?
>

Frankly, the dimension of your case is beyond my experience.
All I can think of is the usual issue:

A separate filesys, or rather a separate *drive*, for swap reduce
butterfly-seeking for the read-write arm in the drive, because the
drive don't have to satisfy regular IO alongside page swapping.
This makes the swapping faster and more efficient.

I guess this applies even if you've got local striped raid volumes,
or you swap over a fiber, because in the end it all comes down
on a harddisk (or several).

Best Regards // Love
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20091114/63909ef9/attachment.htm