I have observed the strangest things with SFILTER on a system with SIS-based
motherboards. Apparently it uses special drivers (siside.sys and
sisidex.sys) to speed things up. Incidentally, I’m referring to chipsets
manufactured by Silicon Integrated Systems Corp (www.sis.com).
I tried to remove any variables related to caching by opening a file using
NIFB. Then I used filemon to look at the activity on both a “normal” and a
sis-based system (both XP).
Here are some sample filemon entries from the “normal” XP system. (I’m using
a specially modified filemon to show more details.) The results are as
expected for a file being opened with NIFB. As you can see from the IRP
Flags, none of the reads are cached.
*myapp.exe IRP_MJ_CREATE c:\mydata\myfile.dat Attributes=80
Options=100084A Access=12019F M=1
*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat FileBasicInformation
*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat FileStandardInformation
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=0 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA0]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=12000 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA0]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=30000 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA0]
Now, here are the same filemon entries from the SIS-based XP system. There
are three strange occurrances.
- The file appears to be closed immediately after opening, even though XP
continues to read from the file!
- Even though filemon clearly shows the file being opened with NIFB, the
IRP Flags show cached reads.
- The IRP_MJ_CREATE has MmIsRecursiveIoFault!=0 [R], which I have never
seen
before.
*myapp.exe IRP_MJ_CREATE c:\mydata\myfile.dat Attributes=80
Options=100084A Access=12019F [R]
*System IRP_MJ_CLOSE c:\mydata\myfile.dat
*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat FileBasicInformation
*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat FileStandardInformation
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=0 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA0]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=0 Len=3000
IRPF=43 FOF=1C0018 [!RMUbS3]
*System IRP_MJ_QI c:\mydata\myfile.dat FileNameInformation
*System IRP_MJ_QI c:\mydata\myfile.dat FileNameInformation
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=12000 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA3]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=12000 Len=3000
IRPF=43 FOF=1C0018 [!RMUbS3]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=30000 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA3]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=30000 Len=3000
IRPF=43 FOF=1C0018 [!RMUbS3]
Can anyone give some suggestions on what is going on here? Are the SIS
drivers doing some sort of intermediate caching and “subverting” the intent
of NIFB?
Thanks for any ideas.
I think you will have to use the debugger to figure
what’s guing on there.
L.
That’s what I’ve been doing for the last couple of weeks, and how I amassed
all the information.
I was asking if the data suggested anything to anyone.
----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Monday, February 28, 2005 3:07 AM
Subject: Re: [ntfsd] strange doings with sfilter and SIS-based chipsets
I think you will have to use the debugger to figure
what’s guing on there.
L.
I don’t think the IDE drivers are going to have any effect on caching in
the file system.
Is there any chance that the file on the SIS system is compressed? No
intermediate buffering is ignored for compressed files. They are always
cached.
At 04:47 PM 2/26/2005 -0500, you wrote:
I have observed the strangest things with SFILTER on a system with SIS-based
motherboards. Apparently it uses special drivers (siside.sys and
sisidex.sys) to speed things up. Incidentally, I’m referring to chipsets
manufactured by Silicon Integrated Systems Corp (www.sis.com).
I tried to remove any variables related to caching by opening a file using
NIFB. Then I used filemon to look at the activity on both a “normal” and a
sis-based system (both XP).
Here are some sample filemon entries from the “normal” XP system. (I’m using
a specially modified filemon to show more details.) The results are as
expected for a file being opened with NIFB. As you can see from the IRP
Flags, none of the reads are cached.
*myapp.exe IRP_MJ_CREATE c:\mydata\myfile.dat Attributes=80
Options=100084A Access=12019F M=1
*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat FileBasicInformation
*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat FileStandardInformation
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=0 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA0]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=12000 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA0]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=30000 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA0]
Now, here are the same filemon entries from the SIS-based XP system. There
are three strange occurrances.
- The file appears to be closed immediately after opening, even though XP
continues to read from the file!
- Even though filemon clearly shows the file being opened with NIFB, the
IRP Flags show cached reads.
- The IRP_MJ_CREATE has MmIsRecursiveIoFault!=0 [R], which I have never
seen
before.
*myapp.exe IRP_MJ_CREATE c:\mydata\myfile.dat Attributes=80
Options=100084A Access=12019F [R]
*System IRP_MJ_CLOSE c:\mydata\myfile.dat
*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat FileBasicInformation
*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat FileStandardInformation
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=0 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA0]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=0 Len=3000
IRPF=43 FOF=1C0018 [!RMUbS3]
*System IRP_MJ_QI c:\mydata\myfile.dat FileNameInformation
*System IRP_MJ_QI c:\mydata\myfile.dat FileNameInformation
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=12000 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA3]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=12000 Len=3000
IRPF=43 FOF=1C0018 [!RMUbS3]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=30000 Len=2000
IRPF=901 FOF=1C0018 [ZrmUbA3]
*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=30000 Len=3000
IRPF=43 FOF=1C0018 [!RMUbS3]
Can anyone give some suggestions on what is going on here? Are the SIS
drivers doing some sort of intermediate caching and “subverting” the intent
of NIFB?
Thanks for any ideas.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks for the suggestion - no they are not compressed files. There seem to
be two boot-time drivers involved: syside.sys which is Group “System Bus
Extended”; and sysidex.sys which has no Group so is loaded last. It is
almost as if they are creating a separate file system on top of ntfs.
Weird. Doesn’t make sense.
----- Original Message -----
From: “Dan Kyler”
To: “Windows File Systems Devs Interest List”
Sent: Monday, February 28, 2005 12:22 PM
Subject: Re: [ntfsd] strange doings with sfilter and SIS-based chipsets
> I don’t think the IDE drivers are going to have any effect on caching in
> the file system.
>
> Is there any chance that the file on the SIS system is compressed? No
> intermediate buffering is ignored for compressed files. They are always
> cached.
>
> - Dan.
>
> At 04:47 PM 2/26/2005 -0500, you wrote:
> >I have observed the strangest things with SFILTER on a system with
SIS-based
> >motherboards. Apparently it uses special drivers (siside.sys and
> >sisidex.sys) to speed things up. Incidentally, I’m referring to chipsets
> >manufactured by Silicon Integrated Systems Corp (www.sis.com).
> >
> >I tried to remove any variables related to caching by opening a file
using
> >NIFB. Then I used filemon to look at the activity on both a “normal” and
a
> >sis-based system (both XP).
> >
> >Here are some sample filemon entries from the “normal” XP system. (I’m
using
> >a specially modified filemon to show more details.) The results are as
> >expected for a file being opened with NIFB. As you can see from the IRP
> >Flags, none of the reads are cached.
> >
> >*myapp.exe IRP_MJ_CREATE c:\mydata\myfile.dat Attributes=80
> >Options=100084A Access=12019F M=1
> >*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat FileBasicInformation
> >*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat
FileStandardInformation
> >*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=0 Len=2000
> >IRPF=901 FOF=1C0018 [ZrmUbA0]
> >*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=12000 Len=2000
> >IRPF=901 FOF=1C0018 [ZrmUbA0]
> >*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=30000 Len=2000
> >IRPF=901 FOF=1C0018 [ZrmUbA0]
> >
> >Now, here are the same filemon entries from the SIS-based XP system.
There
> >are three strange occurrances.
> >1) The file appears to be closed immediately after opening, even though
XP
> >continues to read from the file!
> >2) Even though filemon clearly shows the file being opened with NIFB, the
> >IRP Flags show cached reads.
> >3) The IRP_MJ_CREATE has MmIsRecursiveIoFault!=0 [R], which I have never
> >seen
> >before.
> >
> >*myapp.exe IRP_MJ_CREATE c:\mydata\myfile.dat Attributes=80
> >Options=100084A Access=12019F [R]
> >*System IRP_MJ_CLOSE c:\mydata\myfile.dat
> >*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat FileBasicInformation
> >*myapp.exe IRP_MJ_QI c:\mydata\myfile.dat
FileStandardInformation
> >*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=0 Len=2000
> >IRPF=901 FOF=1C0018 [ZrmUbA0]
> >*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=0 Len=3000
> >IRPF=43 FOF=1C0018 [!RMUbS3]
> >*System IRP_MJ_QI c:\mydata\myfile.dat FileNameInformation
> >*System IRP_MJ_QI c:\mydata\myfile.dat FileNameInformation
> >*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=12000 Len=2000
> >IRPF=901 FOF=1C0018 [ZrmUbA3]
> >*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=12000 Len=3000
> >IRPF=43 FOF=1C0018 [!RMUbS3]
> >*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=30000 Len=2000
> >IRPF=901 FOF=1C0018 [ZrmUbA3]
> >*myapp.exe IRP_MJ_READ c:\mydata\myfile.dat Offset=30000 Len=3000
> >IRPF=43 FOF=1C0018 [!RMUbS3]
> >
> >Can anyone give some suggestions on what is going on here? Are the SIS
> >drivers doing some sort of intermediate caching and “subverting” the
intent
> >of NIFB?
> >
> >Thanks for any ideas.
> >
> >
> >
> >—
> >Questions? First check the IFS FAQ at
> >https://www.osronline.com/article.cfm?id=17
> >
> >You are currently subscribed to ntfsd as: xxxxx@privtek.com
> >To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@netlib.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
xxxxx@lists.osr.com wrote on 02/28/2005 11:01:44 AM:
Thanks for the suggestion - no they are not compressed files. There seem
to
be two boot-time drivers involved: syside.sys which is Group “System Bus
Extended”; and sysidex.sys which has no Group so is loaded last. It is
almost as if they are creating a separate file system on top of ntfs.
Weird. Doesn’t make sense.
Those are the SIS-dependent ATAPI mini-drivers necessary for ATAPI.sys to
run on your hardware. Get it out of your head that these ATA drivers are
doing anything above the FS. It’s not happening. (OK, since I haven’t
grovelled through the source, I can’t state that in absolute terms.
However, you’re more likely to get struck by lightning or win the lottery
than it is likely that those ATA mini drivers are doing what you think
they are doing.)
So try to step back and see if there is anything else that might be
different between the two systems besides the hardware. What is your
“normal” system? Is it running a SCSI disk? An ATA disk through an Intel
ICH system? Do you have a virus scanner or firewall on one system, but
not the other?
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
Besides the fact that the SIS-based motherboard has most everything
on-board, I can’t see any other difference. They both use IDE for both the
hard drive and the CD. There is no SCSI (the SIS board might have on-board
SCSI, but it is not being used for anything). Both use bare-bones Windows
XP + SP1 with no additional software. No firewalls, no AV, no nothing.
I am not saying the siside is doing anything “wrong”. I’m trying to figure
out what is going on. Does the filemon output tell you anything?
Thanks for the reply. As the SIS-based motherboards become more prevalent,
all of us are going to have to deal with them. (Although no major system
vendors use them yet as far as I can tell.)
----- Original Message -----
From: “Philip D Barila”
To: “Windows File Systems Devs Interest List”
Sent: Monday, February 28, 2005 1:29 PM
Subject: Re: [ntfsd] strange doings with sfilter and SIS-based chipsets
> xxxxx@lists.osr.com wrote on 02/28/2005 11:01:44 AM:
>
> > Thanks for the suggestion - no they are not compressed files. There seem
> to
> > be two boot-time drivers involved: syside.sys which is Group “System Bus
> > Extended”; and sysidex.sys which has no Group so is loaded last. It is
> > almost as if they are creating a separate file system on top of ntfs.
> > Weird. Doesn’t make sense.
>
> Those are the SIS-dependent ATAPI mini-drivers necessary for ATAPI.sys to
> run on your hardware. Get it out of your head that these ATA drivers are
> doing anything above the FS. It’s not happening. (OK, since I haven’t
> grovelled through the source, I can’t state that in absolute terms.
> However, you’re more likely to get struck by lightning or win the lottery
> than it is likely that those ATA mini drivers are doing what you think
> they are doing.)
>
> So try to step back and see if there is anything else that might be
> different between the two systems besides the hardware. What is your
> “normal” system? Is it running a SCSI disk? An ATA disk through an Intel
> ICH system? Do you have a virus scanner or firewall on one system, but
> not the other?
>
> Phil
>
> Philip D. Barila
> Seagate Technology LLC
> (720) 684-1842
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@netlib.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
xxxxx@lists.osr.com wrote on 02/28/2005 03:41:57 PM:
Besides the fact that the SIS-based motherboard has most everything
on-board, I can’t see any other difference. They both use IDE for both
the
hard drive and the CD. There is no SCSI (the SIS board might have
on-board
SCSI, but it is not being used for anything). Both use bare-bones
Windows
XP + SP1 with no additional software. No firewalls, no AV, no nothing.
I am not saying the siside is doing anything “wrong”. I’m trying to
figure
out what is going on. Does the filemon output tell you anything?
Thanks for the reply. As the SIS-based motherboards become more
prevalent,
all of us are going to have to deal with them. (Although no major
system
vendors use them yet as far as I can tell.)
If you are literally using XP with SP1, with no additional updates, I hope
it’s not connected to a network that ever connects to the Internet.
Infection could be sufficient to explain your differences.
You are looking at the differences you are observing from the bottom up.
You should be looking from the top down. The FS driver sits above the
disk class driver, which sits above the port driver. The ATAPI port
driver additionally sits above an ATA minidriver. The port driver
controls access to the hardware. You are observing differences from above
the FS. Look for differences in the stack above the FS. Use the various
stack tools available from OSR and/or SysInternals, and IrpTracker, to
figure out what’s different in the FS stack, on the volume, not the device
stack below it.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
There are no viruses or infections. These are both test machines
that have XP installed fresh on them.
----- Original Message -----
From: “Philip D Barila”
To: “Windows File Systems Devs Interest List”
Sent: Monday, February 28, 2005 6:14 PM
Subject: Re: [ntfsd] strange doings with sfilter and SIS-based chipsets
> xxxxx@lists.osr.com wrote on 02/28/2005 03:41:57 PM:
>
> > Besides the fact that the SIS-based motherboard has most everything
> > on-board, I can’t see any other difference. They both use IDE for both
> the
> > hard drive and the CD. There is no SCSI (the SIS board might have
> on-board
> > SCSI, but it is not being used for anything). Both use bare-bones
> Windows
> > XP + SP1 with no additional software. No firewalls, no AV, no nothing.
> >
> > I am not saying the siside is doing anything “wrong”. I’m trying to
> figure
> > out what is going on. Does the filemon output tell you anything?
> >
> > Thanks for the reply. As the SIS-based motherboards become more
> prevalent,
> > all of us are going to have to deal with them. (Although no major
> system
> > vendors use them yet as far as I can tell.)
>
> If you are literally using XP with SP1, with no additional updates, I hope
> it’s not connected to a network that ever connects to the Internet.
> Infection could be sufficient to explain your differences.
>
> You are looking at the differences you are observing from the bottom up.
> You should be looking from the top down. The FS driver sits above the
> disk class driver, which sits above the port driver. The ATAPI port
> driver additionally sits above an ATA minidriver. The port driver
> controls access to the hardware. You are observing differences from above
> the FS. Look for differences in the stack above the FS. Use the various
> stack tools available from OSR and/or SysInternals, and IrpTracker, to
> figure out what’s different in the FS stack, on the volume, not the device
> stack below it.
>
> Phil
>
> Philip D. Barila
> Seagate Technology LLC
> (720) 684-1842
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@netlib.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> There are no viruses or infections. These are both test machines
that have XP installed fresh on them.
Could you try my “FileTest” tool (available for download
at OSR) ?
It is able to issue one exactly defined operation (create,
read, write, …)
Maybe if you combine it with filemon and compare the output
with the “normal” (read : non-SIS) computer, it might tell
you something.
L.
Ladislav - thanks for the reply. Maybe you missed the first message, but I
already did filemon. It was originally in-line, so maybe it was a bit hard
to follow. Instead, here it is as a text file link:
http://netlib.com/files/ntfsd-sis.txt
I will also try your filetest tool.
Thanks again. Neil
----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, March 01, 2005 1:18 AM
Subject: Re: [ntfsd] strange doings with sfilter and SIS-based chipsets
> > There are no viruses or infections. These are both test machines
> > that have XP installed fresh on them.
>
> Could you try my “FileTest” tool (available for download
> at OSR) ?
>
> It is able to issue one exactly defined operation (create,
> read, write, …)
>
> Maybe if you combine it with filemon and compare the output
> with the “normal” (read : non-SIS) computer, it might tell
> you something.
>
> L.
>
> Ladislav - thanks for the reply. Maybe you missed the first message, but
I
already did filemon.
Well, I probably haven’t explained enough what I mean.
What I wanted to say is that try the test tool
because it can generate one (and only one)
certain request, that you can monitor.
E.g. If you press the “NtCreate” button, normally
you should see exactly one IRP_MJ_CREATE
request.
If you will see something more (e.g. additional creates,
additional reads, or additional anything, it means that
you have more filters in the system (e.g. antiviruses
usually generate additional file open(s) and/or read(s),
various other software might generate various additional
requests).
I think (as one of the prev posts said) that the problem is not in the
SiS based chipsets, but in some software installed with
them (didn’t you install some system tool from the firmware CD ?)
I also can suggest you to set breakpoint in some base
file system’s code (try NtfsCommonCreate)
and look to the call stack, to see what filters are above NTFS.
You also can try DeviceTree from OSR, it is able to show you
the devices attached to NTFS (or whatever file system you use)
L.
I put together some additional information on this problem. To refresh the
collective memory, I am having a problem because my filter expects a file
that is opened with NIFB to be non-cached. However, SIS-based motherboards
seem to ignore the NIFB flag.
I used filemon and Ladislav’s great FileTest utility to produce an output
(pdf)
for both a SIS and non-SIS system (say that three times fast! 
It is at
http://netlib.com/files/filetest2.pdf.
The pdf shows the Filemon results of using FileTest to open a file, read,
and close a file. I modified Filemon to include a lot of additional info.
In all cases, the test uses FILE_FLAG_NO_BUFFERING. As you can see from the
Create Options, this is correctly being passed down as the NIFB flag.
The SIS-based motherboard showed two different basic variations that seemed
to toggle back and forth without any apparent reason. I included both of
these as Variation #1 and #2. The “normal” motherboard showed the same
operation every time.
These are both using XP Professional with SP1 but no other software. They
are both freshly installed, so there are no virus scanners, or viruses.
I also included a screenshot of the DeviceTree screenshot for both:
SIS-based DeviceTree is at http://netlib.com/files/sis-tree.jpg
Non-SIS DeviceTree is http://netlib.com/files/non-sis-tree.jpg
I’d greatly appreciate any insight on this. I am sure others will run into
similar problems as SIS motherboards become more prevalent.
Neil
Sorry if this appears twice. I forgot to use an internet friendly format
the first time, and I think Lyris silently rejected it.
Goodness! It looks like the sisidex is a software caching filter.
See if it’s a filter using filterman, or manually inspect the class GUID
keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class and search for
“sisidex” without the quotes.
If it’s in an UpperFilters or LowerFilters value, you should be able to
remove it safely and the system should behave the same.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
xxxxx@lists.osr.com wrote on 03/10/2005 10:18:39 AM:
I put together some additional information on this problem. To refresh
the
collective memory, I am having a problem because my filter expects a
file
that is opened with NIFB to be non-cached. However, SIS-based
motherboards
seem to ignore the NIFB flag.
I used filemon and Ladislav’s great FileTest utility to produce an
output
(pdf)
for both a SIS and non-SIS system (say that three times fast! It is
at
http://netlib.com/files/filetest2.pdf.
The pdf shows the Filemon results of using FileTest to open a file,
read,
and close a file. I modified Filemon to include a lot of additional
info.
In all cases, the test uses FILE_FLAG_NO_BUFFERING. As you can see from
the
Create Options, this is correctly being passed down as the NIFB flag.
The SIS-based motherboard showed two different basic variations that
seemed
to toggle back and forth without any apparent reason. I included both
of
these as Variation #1 and #2. The “normal” motherboard showed the same
operation every time.
These are both using XP Professional with SP1 but no other software.
They
are both freshly installed, so there are no virus scanners, or viruses.
I also included a screenshot of the DeviceTree screenshot for both:
SIS-based DeviceTree is at http://netlib.com/files/sis-tree.jpg
Non-SIS DeviceTree is http://netlib.com/files/non-sis-tree.jpg
I’d greatly appreciate any insight on this. I am sure others will run
into
similar problems as SIS motherboards become more prevalent.
Neil
Questions? First check the IFS FAQ at https://www.osronline.
com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I have examined the “SiS cases” and “Non-SiS cases”
in the docs from Neil Weicher.
The differences between them seem to be the same
like the difference between working
with NTFS-compressed and uncompressed file
Isn’t that the case ?
L.
Philip,
Thanks for the reply. No apparent reference to sisidex in that registry
key. One key seems to reference siside. I put the Regedit export in:
http://netlib.com/files/class-reg.txt . I removed the quotes (") for
readability.
In addition, I exported the registry service entries for siside and sisidex.
Even though sisidex is not marked as a filter, it appears to be acting as
one. They are in, respectively, http://netlib.com/files/siside-reg.txt and
http://netlib.com/files/sisidex-reg.txt
I also compiled some additional information.
Last time I posted the DeviceTree of Ntfs
(http://netlib.com/files/sis-tree.jpg).
This time I added:
DeviceTree of siside: http://netlib.com/files/tree-siside.jpg
DeviceTree of sisidex: http://netlib.com/files/tree-sisidex.jpg
LoadOrder for siside: http://netlib.com/files/order-siside.jpg
LoadOrder for sisidex: http://netlib.com/files/order-sisidex.jpg
Does this tell you anything more?
I think this is important, because there are already some system vendors
(e.g., Gigbyte) starting to use these chips. And users are being told they
must use the SIS provided drivers.
Thanks.
----- Original Message -----
From: “Philip D Barila”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, March 10, 2005 1:30 PM
Subject: Re: [ntfsd] strange doings with sfilter and SIS-based chipsets
Goodness! It looks like the sisidex is a software caching filter.
See if it’s a filter using filterman, or manually inspect the class GUID
keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class and search for
“sisidex” without the quotes.
If it’s in an UpperFilters or LowerFilters value, you should be able to
remove it safely and the system should behave the same.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
xxxxx@lists.osr.com wrote on 03/10/2005 10:18:39 AM:
> I put together some additional information on this problem. To refresh
the
> collective memory, I am having a problem because my filter expects a
file
> that is opened with NIFB to be non-cached. However, SIS-based
motherboards
> seem to ignore the NIFB flag.
>
> I used filemon and Ladislav’s great FileTest utility to produce an
output
> (pdf)
> for both a SIS and non-SIS system (say that three times fast! It is
at
> http://netlib.com/files/filetest2.pdf.
>
> The pdf shows the Filemon results of using FileTest to open a file,
read,
> and close a file. I modified Filemon to include a lot of additional
info.
>
> In all cases, the test uses FILE_FLAG_NO_BUFFERING. As you can see from
the
> Create Options, this is correctly being passed down as the NIFB flag.
>
> The SIS-based motherboard showed two different basic variations that
seemed
> to toggle back and forth without any apparent reason. I included both
of
> these as Variation #1 and #2. The “normal” motherboard showed the same
> operation every time.
>
> These are both using XP Professional with SP1 but no other software.
They
> are both freshly installed, so there are no virus scanners, or viruses.
>
> I also included a screenshot of the DeviceTree screenshot for both:
> SIS-based DeviceTree is at http://netlib.com/files/sis-tree.jpg
> Non-SIS DeviceTree is http://netlib.com/files/non-sis-tree.jpg
>
> I’d greatly appreciate any insight on this. I am sure others will run
into
> similar problems as SIS motherboards become more prevalent.
>
> Neil
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.
> com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@seagate.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@netlib.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Well, the problem is solved! The SISIDE drivers came with a stealth
“performance enhancing cache”. It was, in fact, caching files even if they
were opened with NIFB! I disabled the cache and the problem went away.
> Well, the problem is solved! The SISIDE drivers came with a stealth
“performance enhancing cache”. It was, in fact, caching files even if they
were opened with NIFB! I disabled the cache and the problem went away.
Well, I really “like” such driver, which creates yet another
different behavior of the ile system. IHMO when someone
wants the file to be open noncached, (s)he usually knows why.
And even more, number of files opened noncached is very small
so I don’t believe it will have any influence to the system performance.
L.
