A reimplementation of reactos' cache manager supporting alternate filesystems better (including ext2)

I'm pleased to announce that I've been able to boot reactos to the shell from an ext2 partition.  This is something we've wanted for a long time and many of us have worked on.  I've synced up arty-newcc to the current state of my git repository.  This work is experimental, not quite complete, and has some important limitations:

- It probably won't currently work for a partition larger than 4gig and might even fail for one larger than 2gig.  This limitation is lifted by other, unrelated code in my tree that I haven't merged yet.

- It probably has a lot more bugs left, especially in block allocation for large files.

- Some parts of the new section implementation leak pages.

I was planning to, but haven't yet made the new and old cache and cc and section implementations available side by side.  The main work of separating the new files involved in the section implementation (now in ntoskrnl/mm/section/*) is done. This will be necessary when I merge it into the main tree, at least for regression testing.

Despite the branch being named for me, I invite anyone to work on, modify, or bugfix arty-newcc.  This advance has been a long time coming, and I'd like to thank everyone for keeping the faith.

[Aleksey Bragin]

That's great! This gives me more motivation to finish the fastfat  
rewrite and test your branch with that driver.

On Nov 9, 2009, at 12:21 PM, [e-mail]  
[e-mail] wrote:
> I'm pleased to announce that I've been able to boot reactos to the  
> shell from an ext2 partition.  This is something we've wanted for a  
> long time and many of us have worked on.  I've synced up arty-newcc  
> to the current state of my git repository.  This work is  
> experimental, not quite complete, and has some important limitations:
> It probably won't currently work for a partition larger than 4gig
>
> and might even fail for one larger than 2gig.  This limitation is  
> lifted by other, unrelated code in my tree that I haven't merged yet.
> It probably has a lot more bugs left, especially in block
>
> allocation for large files.
> Some parts of the new section implementation leak pages.
>
> I was planning to, but haven't yet made the new and old cache and  
> cc and section implementations available side by side.  The main  
> work of separating the new files involved in the section  
> implementation (now in ntoskrnl/mm/section/*) is done. This will be  
> necessary when I merge it into the main tree, at least for  
> regression testing.
>
> Despite the branch being named for me, I invite anyone to work on,  
> modify, or bugfix arty-newcc.  This advance has been a long time  
> coming, and I'd like to thank everyone for keeping the faith.

[Javier Agustìn Fernàndez Arroyo]

keep up the awesome work guys!

On Mon, Nov 9, 2009 at 10:51 AM, Aleksey Bragin [e-mail] wrote:
> That's great! This gives me more motivation to finish the fastfat
> rewrite and test your branch with that driver.
>
> On Nov 9, 2009, at 12:21 PM, [e-mail]
> [e-mail] wrote:
> > I'm pleased to announce that I've been able to boot reactos to the
> > shell from an ext2 partition.  This is something we've wanted for a
> > long time and many of us have worked on.  I've synced up arty-newcc
> > to the current state of my git repository.  This work is
> > experimental, not quite complete, and has some important limitations:
> > It probably won't currently work for a partition larger than 4gig
> >
> > and might even fail for one larger than 2gig.  This limitation is
> > lifted by other, unrelated code in my tree that I haven't merged yet.
> > It probably has a lot more bugs left, especially in block
> >
> > allocation for large files.
> > Some parts of the new section implementation leak pages.
> >
> > I was planning to, but haven't yet made the new and old cache and
> > cc and section implementations available side by side.  The main
> > work of separating the new files involved in the section
> > implementation (now in ntoskrnl/mm/section/*) is done. This will be
> > necessary when I merge it into the main tree, at least for
> > regression testing.
> >
> > Despite the branch being named for me, I invite anyone to work on,
> > modify, or bugfix arty-newcc.  This advance has been a long time
> > coming, and I'd like to thank everyone for keeping the faith.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[James Walmsley]

Hi,

The other day I had an idea. Because Linux has already many
file-systems, would it not be possible to simply make a generic FS
driver, that simply wraps around the Linux fs model?

I'm sure the linux and windows models are quite different when it
comes to their overall architecture.

The advantage of doing this would be that we'd have instant access to
well tested and maintained code.

This is essentially what Aleksey is doing with my FullFAT library,
albeit with a few small modifications.

Kind Regards

James

2009/11/9 Aleksey Bragin [e-mail]:
> That's great! This gives me more motivation to finish the fastfat
> rewrite and test your branch with that driver.
>
> On Nov 9, 2009, at 12:21 PM, [e-mail]
> [e-mail] wrote:
> > I'm pleased to announce that I've been able to boot reactos to the
> > shell from an ext2 partition.  This is something we've wanted for a
> > long time and many of us have worked on.  I've synced up arty-newcc
> > to the current state of my git repository.  This work is
> > experimental, not quite complete, and has some important limitations:
> > It probably won't currently work for a partition larger than 4gig
> >
> > and might even fail for one larger than 2gig.  This limitation is
> > lifted by other, unrelated code in my tree that I haven't merged yet.
> > It probably has a lot more bugs left, especially in block
> >
> > allocation for large files.
> > Some parts of the new section implementation leak pages.
> >
> > I was planning to, but haven't yet made the new and old cache and
> > cc and section implementations available side by side.  The main
> > work of separating the new files involved in the section
> > implementation (now in ntoskrnl/mm/section/*) is done. This will be
> > necessary when I merge it into the main tree, at least for
> > regression testing.
> >
> > Despite the branch being named for me, I invite anyone to work on,
> > modify, or bugfix arty-newcc.  This advance has been a long time
> > coming, and I'd like to thank everyone for keeping the faith.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
James Walmsley
----------------------------------------
[e-mail]

[King InuYasha]

Wouldn't that mean that we would need to support the extended attributes
that Linux drivers support within ReactOS (like UNIX permissions, etc.)?

On Tue, Nov 10, 2009 at 3:18 PM, James Walmsley [e-mail] wrote:
> Hi,
>
> The other day I had an idea. Because Linux has already many
> file-systems, would it not be possible to simply make a generic FS
> driver, that simply wraps around the Linux fs model?
>
> I'm sure the linux and windows models are quite different when it
> comes to their overall architecture.
>
> The advantage of doing this would be that we'd have instant access to
> well tested and maintained code.
>
> This is essentially what Aleksey is doing with my FullFAT library,
> albeit with a few small modifications.
>
> Kind Regards
>
> James
>
> 2009/11/9 Aleksey Bragin [e-mail]:
> > That's great! This gives me more motivation to finish the fastfat
> > rewrite and test your branch with that driver.
> >
> > On Nov 9, 2009, at 12:21 PM, [e-mail]
> > [e-mail] wrote:
> > > I'm pleased to announce that I've been able to boot reactos to the
> > > shell from an ext2 partition.  This is something we've wanted for a
> > > long time and many of us have worked on.  I've synced up arty-newcc
> > > to the current state of my git repository.  This work is
> > > experimental, not quite complete, and has some important limitations:
> > > It probably won't currently work for a partition larger than 4gig
> > >
> > > and might even fail for one larger than 2gig.  This limitation is
> > > lifted by other, unrelated code in my tree that I haven't merged yet.
> > > It probably has a lot more bugs left, especially in block
> > >
> > > allocation for large files.
> > > Some parts of the new section implementation leak pages.
> > >
> > > I was planning to, but haven't yet made the new and old cache and
> > > cc and section implementations available side by side.  The main
> > > work of separating the new files involved in the section
> > > implementation (now in ntoskrnl/mm/section/*) is done. This will be
> > > necessary when I merge it into the main tree, at least for
> > > regression testing.
> > >
> > > Despite the branch being named for me, I invite anyone to work on,
> > > modify, or bugfix arty-newcc.  This advance has been a long time
> > > coming, and I'd like to thank everyone for keeping the faith.
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> --
> James Walmsley
>
> [e-mail]
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Love Nystrom]

On Wed, Nov 11, 2009 at 4:32 AM, King InuYasha [e-mail] wrote:
> Wouldn't that mean that we would need to support the extended attributes
> that Linux drivers support within ReactOS (like UNIX permissions, etc.)?

They just need to be mapped to equivalent NT security attributes.

On Tue, Nov 10, 2009 at 3:18 PM, James Walmsley [e-mail] wrote:
> > Hi,
> >
> > The other day I had an idea. Because Linux has already many
> > file-systems, would it not be possible to simply make a generic FS
> > driver, that simply wraps around the Linux fs model?

That's a good idea. An IFS (installable file system) driver is the
proper way to implement ext3/ext2 or other file systems support in NT.
Is Ayerkes implementation hard-coded into the kernel?

I'm sure the linux and windows models are quite different when it
> > comes to their overall architecture.

Does the linux fs support extended attributes
that can be used to store access control lists (ACLs)?

If not, the IFS driver can not implement the full NT security model
(neither can FAT), but I think it would still be a good idea to have
an ext2/ext3 IFS driver. Even better if we could support
a journaling fs like f.ex reiserfs.

Best Regards // Love

[Olaf Siejka]

Such driver exists already, http://www.fs-driver.org/ and it's fully IFS.

2009/11/11 Love Nystrom [e-mail]
> If not, the IFS driver can not implement the full NT security model
> (neither can FAT), but I think it would still be a good idea to have
> an ext2/ext3 IFS driver. Even better if we could support
> a journaling fs like f.ex reiserfs.
>
> Best Regards // Love

[Javier Agustìn Fernàndez Arroyo]

This is mostly for James..

Would it be possible to add into fullFAT some kind of "swap partition"
system, as Linux fs´es have?

On Wed, Nov 11, 2009 at 3:18 PM, Olaf Siejka [e-mail] wrote:
> Such driver exists already, http://www.fs-driver.org/ and it's fully IFS.
>
> 2009/11/11 Love Nystrom [e-mail]
> > If not, the IFS driver can not implement the full NT security model
> > (neither can FAT), but I think it would still be a good idea to have
> > an ext2/ext3 IFS driver. Even better if we could support
> > a journaling fs like f.ex reiserfs.
> >
> > Best Regards // Love
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Love Nystrom]

2009/11/11 Javier Agustìn Fernàndez Arroyo [e-mail]
> This is mostly for James..
>  Would it be possible to add into fullFAT some kind of "swap partition"
> system, as Linux fs´es have?

I've found an NT IFS driver for linux swap partitions. Does ROS support IFS
drivers ?
With this driver, f.ex the NT swap file (virtual memory) can reside on a
linux swap partition.
I'll try building it for ROS and testing it when I get some time.

[Aleksey Bragin]

Sorry to answer a question not addressed to me, but, in my opinion, a  
swap partition is not a very optimal way for organizing a swapping  
space nowadays. A swap file is way better in this regard.

To finish my thought, FAT filesystem driver has really nothing to do  
with a swap partition file system. It has something to do with a  
pagefile though.

WBR,
Aleksey.

On Nov 11, 2009, at 6:00 PM, Javier Agustìn Fernàndez Arroyo wrote:
> This is mostly for James..
>
> Would it be possible to add into fullFAT some kind of "swap  
> partition" system, as Linux fs´es have?
>
> On Wed, Nov 11, 2009 at 3:18 PM, Olaf Siejka [e-mail] wrote:
> Such driver exists already, http://www.fs-driver.org/ and it's  
> fully IFS.
>
> 2009/11/11 Love Nystrom [e-mail]
>
> If not, the IFS driver can not implement the full NT security model
> (neither can FAT), but I think it would still be a good idea to have
> an ext2/ext3 IFS driver. Even better if we could support
> a journaling fs like f.ex reiserfs.
>
> Best Regards // Love

[Dmitry Gorbachev]

> in my opinion, a swap partition is not a very optimal way for organizing
> a swapping space nowadays. A swap file is way better in this regard.

It would be easier to share a swap partition between OSes, then a swap file.

[Zachary Gorden]

What point would be served by sharing swap partitions?

On Wed, Nov 11, 2009 at 11:59 AM, Dmitry Gorbachev [e-mail]:
> > in my opinion, a swap partition is not a very optimal way for organizing
> > a swapping space nowadays. A swap file is way better in this regard.
>
> It would be easier to share a swap partition between OSes, then a swap
> file.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Dmitry Gorbachev]

> What point would be served by sharing swap partitions?

An economy of space.

[Dmitry Gorbachev]

Also, the installer can impress people by its courtesy (as vmwinst
already does), if it will recognize existing swap partitions and offer
to reuse them in reactos. :)
> > What point would be served by sharing swap partitions?
>
> An economy of space.

[Alexandru Lovin]

Doesn't Win 7 already make a separate swap partition?

On Wed, Nov 11, 2009 at 9:47 PM, Dmitry Gorbachev [e-mail]:
> Also, the installer can impress people by its courtesy (as vmwinst
> already does), if it will recognize existing swap partitions and offer
> to reuse them in reactos. :)
> > > What point would be served by sharing swap partitions?
> >
> > An economy of space.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[King InuYasha]

No.

On Wed, Nov 11, 2009 at 2:27 PM, Alexandru Lovin [e-mail] wrote:
> Doesn't Win 7 already make a separate swap partition?
>
> On Wed, Nov 11, 2009 at 9:47 PM, Dmitry Gorbachev [e-mail]:
> > Also, the installer can impress people by its courtesy (as vmwinst
> > already does), if it will recognize existing swap partitions and offer
> > to reuse them in reactos. :)
> > > > What point would be served by sharing swap partitions?
> > >
> > > An economy of space.
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Brian]

i was always under the impression that having a swap partition meant that
you did not have to hassle with the file system allowing for
marginal performance boosts.
-- 
brian

[Love Nystrom]

Brian wrote:
> i was always under the impression that having a swap 
> partition meant that you did not have to hassle with the file system 
> allowing for marginal performance boosts.

That is generally true. In theory, APIs to access a swap partition can be
implemented to use the disk device driver directly, removing the additional
processing incurred by file systems drivers.

In practice on NT, I believe the proper way is to implement a swap
file system driver, which can be made more efficient than regular
file systems drivers.

[Alex Ionescu]

It's always funny to see how most people on this list talking about NT
really have no clue.

There would be no advantage to have a swap partition on Windows. Fast
I/O and Paging I/O more than make up for any "benefits" Linux has.
It's easy to have benefits to skip your FS when your FS model is
worthless. It becomes a much mooter point when your FS model is the
size and complexity (in terms of performance) of the competition's
kernel. Not to mention you could forget about crash dumps with a
separate partition.

And no, Windows 7 sets up a separate system volume (this is where boot
files go) to separate from the Win7 boot volume (this is where the
Windows system files go) and to allow BitLocker to work.

Best regards,
Alex Ionescu

On Thu, Nov 12, 2009 at 3:18 AM, Love Nystrom [e-mail] wrote:
> Brian wrote:
> > i was always under the impression that having a swap
> > partition meant that you did not have to hassle with the file system
> > allowing for marginal performance boosts.
>
> That is generally true. In theory, APIs to access a swap partition can be
> implemented to use the disk device driver directly, removing the additional
> processing incurred by file systems drivers.
>
> In practice on NT, I believe the proper way is to implement a swap
> file system driver, which can be made more efficient than regular
> file systems drivers.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

You've spoiled the fun.
I've was enjoying watching this rather weird discussion pan out.

What's next? Compiling drivers into the kernel?

:)

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Alex Ionescu
Sent: 12 November 2009 15:43
To: ReactOS Development List
Subject: Re: [ros-dev] A reimplementation of reactos' cache manager
supporting alternate filesystems better (including ext2)

It's always funny to see how most people on this list talking about NT
really have no clue.

There would be no advantage to have a swap partition on Windows. Fast
I/O and Paging I/O more than make up for any "benefits" Linux has.
It's easy to have benefits to skip your FS when your FS model is
worthless. It becomes a much mooter point when your FS model is the
size and complexity (in terms of performance) of the competition's
kernel. Not to mention you could forget about crash dumps with a
separate partition.

And no, Windows 7 sets up a separate system volume (this is where boot
files go) to separate from the Win7 boot volume (this is where the
Windows system files go) and to allow BitLocker to work.

Best regards,
Alex Ionescu

On Thu, Nov 12, 2009 at 3:18 AM, Love Nystrom [e-mail]
wrote:
> Brian wrote:
> > i was always under the impression that having a swap
> > partition meant that you did not have to hassle with the file system
> > allowing for marginal performance boosts.
>
> That is generally true. In theory, APIs to access a swap partition can be
> implemented to use the disk device driver directly, removing the

additional
> processing incurred by file systems drivers.
>
> In practice on NT, I believe the proper way is to implement a swap
> file system driver, which can be made more efficient than regular
> file systems drivers.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Love Nystrom]

Ged Murphy wrote:
> What's next? Compiling drivers into the kernel?

That's Linux I believe.. :-D   
What's wrong with installable file system drivers?

[Love Nystrom]

Alex Ionescu wrote:
> There would be no advantage to have a swap partition on Windows.

There most certainly is, if that partition is on another physical drive!
Two disks are faster than one  ;-)
> Not to mention you could forget about crash dumps with a
> separate partition.

Enlighten me.. Why?

[Alex Ionescu]

1) You would get the SAME ADVANTAGE by having the FILE on another
physical drive!
2) I believe there's a book that covers that? Not to mention a bunch
of easily googable information.

Best regards,
Alex Ionescu

On Thu, Nov 12, 2009 at 11:37 AM, Love Nystrom [e-mail] wrote:
> Alex Ionescu wrote:
> > There would be no advantage to have a swap partition on Windows.
>
> There most certainly is, if that partition is on another physical drive!
> Two disks are faster than one  ;-)
> > Not to mention you could forget about crash dumps with a
> > separate partition.
>
> Enlighten me.. Why?
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Love Nystrom]

Alex Ionescu wrote:
> You would get the SAME ADVANTAGE by having the FILE on another
>
> physical drive!

True enough.
But I believe the issue was if there'd be a point in installing an IFS 
driver
that would enable you to put the swap file on a swap partition.

[Jonas Gorski]

2009/11/12 Love Nystrom [e-mail]:
> But I believe the issue was if there'd be a point in installing an IFS
> driver
> that would enable you to put the swap file on a swap partition.

I think there is, if you have a small hard disk and dual boot with linux.
And to spoil the fun, there already is an IFS driver for that:
SwapFs[1]. And it even is GPL.

Regards,
Jonas Gorski

[1] http://www.acc.umu.se/~bosse/

[Alexandru Lovin]

No one has a small hard disk and dual boots with linux. Nobody uses Linux.
It's not for human beings. I'm afraid you don't exist as a user, either.

Stop trying to make ReactOS into a Windows-compatible, the-Linux-way OS. No
regular Windows user wants the mess of having a gazillion hidden partitions
to take care of not deleting or messing with. Thank you.
> I think there is, if you have a small hard disk and dual boot with linux.
> And to spoil the fun, there already is an IFS driver for that:
> SwapFs[1]. And it even is GPL.
>
> Regards,
> Jonas Gorski
>
> [1] http://www.acc.umu.se/~bosse/
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[King InuYasha]

It's a good thing none of us are regular Windows users then, isn't it? ;)

On Thu, Nov 12, 2009 at 11:19 AM, Alexandru Lovin [e-mail] wrote:
> No one has a small hard disk and dual boots with linux. Nobody uses Linux.
> It's not for human beings. I'm afraid you don't exist as a user, either.
>
> Stop trying to make ReactOS into a Windows-compatible, the-Linux-way OS. No
> regular Windows user wants the mess of having a gazillion hidden partitions
> to take care of not deleting or messing with. Thank you.
> > I think there is, if you have a small hard disk and dual boot with linux.
> > And to spoil the fun, there already is an IFS driver for that:
> > SwapFs[1]. And it even is GPL.
> >
> > Regards,
> > Jonas Gorski
> >
> > [1] http://www.acc.umu.se/~bosse/
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Dmitry Gorbachev]

> Nobody uses Linux.

God grant ReactOS so many users…

[Love Nystrom]

Alex Ionescu wrote:
> > > Not to mention you could forget about crash dumps with a
> > > separate partition.

Alex.. I really don't know.. So please tell me why having the swap file on
a swap partition precludes writing out a crash dump??

[Steven Edwards]

On Thu, Nov 12, 2009 at 11:46 AM, Alex Ionescu [e-mail] wrote:
> 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). This kind of
surprises me because you would think that if your using shared storage
such a NetAPP Filer the IO is spread across all drives anyway so you
save mostly nothing on IO so the only thing I can think is that a
separate filesystem saves a small amount due to consolidation of all
fragments to one location.

...dont even get me started on other trouble I've had with filesystems
and block alignment ;)
-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Steven Edwards]

On Thu, Nov 12, 2009 at 8:29 PM, Steven Edwards [e-mail] wrote:
> On Thu, Nov 12, 2009 at 11:46 AM, Alex Ionescu [e-mail] wrote:
> > 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). This kind of
> surprises me because you would think that if your using shared storage
> such a NetAPP Filer the IO is spread across all drives anyway so you
> save mostly nothing on IO so the only thing I can think is that a
> separate filesystem saves a small amount due to consolidation of all
> fragments to one location.

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.
-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Steven Edwards]

On Thu, Nov 12, 2009 at 8:32 PM, Steven Edwards [e-mail] wrote:
> On Thu, Nov 12, 2009 at 8:29 PM, Steven Edwards [e-mail] wrote:
> > On Thu, Nov 12, 2009 at 11:46 AM, Alex Ionescu [e-mail] wrote:
> > > 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). This kind of
> > surprises me because you would think that if your using shared storage
> > such a NetAPP Filer the IO is spread across all drives anyway so you
> > save mostly nothing on IO so the only thing I can think is that a
> > separate filesystem saves a small amount due to consolidation of all
> > fragments to one location.
>
> 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?

Like I said, using shared storage as a backend be it raided volume,
iscsi, fiberchannel or nfs is in effect the same thing as having one
physical drive since all IO ops are effectively distributed evenly
across all drives, making the volume akin to one physical drive. If
there really is no benefit then they are wrong and having the swap
file on any volume really is fine. Maybe VMware and NetApp are wrong
and just have subscribed to group think.
-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Love Nystrom]

On Fri, Nov 13, 2009 at 10:50 PM, Steven Edwards [e-mail]:
> On Thu, Nov 12, 2009 at 8:32 PM, Steven Edwards [e-mail]
> wrote:
> > On Thu, Nov 12, 2009 at 8:29 PM, Steven Edwards [e-mail]
>
> wrote:
> > > On Thu, Nov 12, 2009 at 11:46 AM, Alex Ionescu [e-mail]
>
> wrote:
> > > > 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

[Love Nystrom]

> Ping? Nobody? So no idea why a separate dedicate virtual drive is
> recommended for the pagefile.sys?

Also, if the swap volume is connected to it's own disk controller, of course

it has an entire IO channel to itself which makes a big difference.

But I don't see how it could apply to a virtual adapter/disk pair.

[Love Nystrom]

> Ping? Nobody? So no idea why a separate dedicate virtual drive is
> > recommended for the pagefile.sys?

Perhaps the virtual disk has a virtual hardware cache
that will be dedicated to swap if it don't need to do other work?

[Love Nystrom]

On Wed, Nov 11, 2009 at 9:18 PM, Olaf Siejka [e-mail] wrote:
> Such driver exists already, http://www.fs-driver.org/ and it's fully IFS.

Stephan only distributes binaries, no source, so his driver is of limited
interest to ROS.
I've found other ext2/ext3 drivers that are better suited for this project.

[Daniel Reimer]

Before you run through all EXT IFS Driver out there, bear in mind, we 
already have on in our tree. If you find a better one, feel free to report.

Love Nystrom schrieb:
> On Wed, Nov 11, 2009 at 9:18 PM, Olaf Siejka <[e-mail] 
> mailto:[e-mail]> wrote:
> Such driver exists already, http://www.fs-driver.org/ and it's
> fully IFS.
>
>
> Stephan only distributes binaries, no source, so his driver is of 
> limited interest to ROS.
> I've found other ext2/ext3 drivers that are better suited for this 
> project.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev