SFS vs NGFS "PROGDIR:/" question
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: SFS vs NGFS "PROGDIR:/" question
I don't know what the effect would be. You could try running Snoopy to see if it can show you what takes a long time (Long reads? Some seeks? Are there Writes at the same time?). That might give you a clue of where to try making changes.
cheers
tony
tony
Re: SFS vs NGFS "PROGDIR:/" question
@tony
I do check with snoopy, and it has loooots of GetFilePosition + ChangeFilePosition . By lots i mean tens of thousands of this type:
On NGFS i didn't notice any slowdowns because of this, but on sfs i can notice those micropauses.
The differences between NGFS and SFS in the snoopy logs, is that for NGFS i have from time to time that:
Is SFS are "cached filesystem", right ?
I do check with snoopy, and it has loooots of GetFilePosition + ChangeFilePosition . By lots i mean tens of thousands of this type:
67247 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 33292 [2uS]
67248 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,526,OFFSET_BEGINNING) [1uS]
67249 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 526 [1uS]
67250 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 526 [1uS]
67251 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,704,OFFSET_BEGINNING) [2uS]
67252 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 704 [1uS]
67253 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 704 [1uS]
67254 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 33472 [2uS]
67255 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,706,OFFSET_BEGINNING) [2uS]
67256 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 706 [1uS]
67257 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 706 [1uS]
67258 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,68644,OFFSET_BEGINNING) [1uS]
67259 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68644 [1uS]
67260 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68644 [1uS]
67261 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 69540 [2uS]
67262 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,68646,OFFSET_BEGINNING) [2uS]
67263 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68646 [1uS]
67264 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68646 [2uS]
67265 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,68824,OFFSET_BEGINNING) [2uS]
67266 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68824 [1uS]
67267 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68824 [1uS]
67268 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 69540 [2uS]
67269 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,68826,OFFSET_BEGINNING) [2uS]
67270 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68826 [2uS]
67271 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68826 [2uS]
67272 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,17216,OFFSET_BEGINNING) [2uS]
67273 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 17216 [1uS]
67274 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 17216 [2uS]
67275 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,524,OFFSET_BEGINNING) [2uS]
67276 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 524 [1uS]
67277 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 524 [1uS]
67278 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 33292 [2uS]
67279 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,526,OFFSET_BEGINNING) [2uS]
67280 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 526 [1uS]
67281 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 526 [1uS]
67282 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 33294 [2uS]
67283 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,528,OFFSET_BEGINNING) [2uS]
67284 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 528 [1uS]
67285 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 528 [1uS]
67286 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,68644,OFFSET_BEGINNING) [1uS]
67287 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68644 [1uS]
67288 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68644 [1uS]
67289 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 69540 [2uS]
67290 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,68646,OFFSET_BEGINNING) [1uS]
67291 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68646 [1uS]
67292 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68646 [1uS]
67293 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 69540 [2uS]
67294 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,68648,OFFSET_BEGINNING) [2uS]
67295 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68648 [1uS]
67296 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 68648 [1uS]
67297 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,17216,OFFSET_BEGINNING) [2uS]
67298 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 17216 [2uS]
67299 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 17216 [2uS]
On NGFS i didn't notice any slowdowns because of this, but on sfs i can notice those micropauses.
The differences between NGFS and SFS in the snoopy logs, is that for NGFS i have from time to time that:
While didn't have that for SFS.56080 : Barony.exe : o.k. = [exec] OpenResource("cacheclearu.resource") [4uS]
56081 : Barony.exe : o.k. = [exec] OpenResource("cacheclearu.resource") [2uS]
Is SFS are "cached filesystem", right ?
- colinw
- AmigaOS Core Developer
- Posts: 207
- Joined: Mon Aug 15, 2011 9:20 am
- Location: Brisbane, QLD. Australia.
Re: SFS vs NGFS "PROGDIR:/" question
I agree, it is a bug, I wrote the function and it's not supposed to do that.salass00 wrote: It's not really a fault though, as "RAM:/" is not a legal path.
If anything the fact that ResolvePath() allows this and treats "PROGDIR:/test.txt" the same as "PROGDIR:test.txt" in the case
where PROGDIR: points to a volume root directory could be considered a bug.
I dug out the test program for ResolvePath() and discovered none of the test cases use an assignment or the
virtual assignments like PROGDIR: or CURRDIR:, so I never noticed this behaviour before.
You can see the problem easily by CD'ing to RAM: and in a shell type; CURRDIR:/ and then; RAM:/
The first doesn't fail while the second one does.
I found the problem and it's now been fixed.
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: SFS vs NGFS "PROGDIR:/" question
Are you sure the GetFilePosition/SetFilePosition calls are causing delays? A couple of microseconds per call sounds OK to me.kas1e wrote:@tony
I do check with snoopy, and it has loooots of GetFilePosition + ChangeFilePosition . By lots i mean tens of thousands of this type:
On NGFS i didn't notice any slowdowns because of this, but on sfs i can notice those micropauses.67247 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 33292 [2uS]
67248 : Barony.exe : o.k. = ChangeFilePosition(0x1A0A1A7E,526,OFFSET_BEGINNING) [1uS]
67249 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 526 [1uS]
67250 : Barony.exe : o.k. = GetFilePosition(0x1A0A1A7E) = 526 [1uS]
...
Those calls are not from NGFS. I don't know where they come from.
The differences between NGFS and SFS in the snoopy logs, is that for NGFS i have from time to time that:
While didn't have that for SFS.56080 : Barony.exe : o.k. = [exec] OpenResource("cacheclearu.resource") [4uS]
56081 : Barony.exe : o.k. = [exec] OpenResource("cacheclearu.resource") [2uS]
Don't confuse the CPU caches (CacheClearU(), etc) with the file system's internal caches ("buffers"). NGFS (and I'm sure SFS does the same) has a number of disk block buffers that it uses to store data temporarily, to reduce the number of disk accesses. They have nothing to do with the CPU's hardware caches.
Is SFS are "cached filesystem", right ?
cheers
tony
tony
- colinw
- AmigaOS Core Developer
- Posts: 207
- Joined: Mon Aug 15, 2011 9:20 am
- Location: Brisbane, QLD. Australia.
Re: SFS vs NGFS "PROGDIR:/" question
Kas1e, seeing you're a betatester, if you download the latest Snoopy 53.44 from the FTP server,
it will show you the name of the file it is doing all those ChangeFilePosition() etc... calls to.
Also, keep in mind that library calls performed by the application show up as from the application,
so it could be calling locale.library or diskfont.library or datatypes any other one that is actually making those calls.
it will show you the name of the file it is doing all those ChangeFilePosition() etc... calls to.
Also, keep in mind that library calls performed by the application show up as from the application,
so it could be calling locale.library or diskfont.library or datatypes any other one that is actually making those calls.
Re: SFS vs NGFS "PROGDIR:/" question
@colinw
Yep will check last snoopy.
What i think about now that if 1:1 the same binary give no micropauses from ram: or from ngfs: (and there on beta both ram: and ngfs: are "new filesystems"), but give them on sfs2, then maybe there some emulation involved to make old filesystems works, and that cause little overhead and small delays ?
I also tryed to play with sfs settings of buffers and blocksizes: does not matter what i have for sfs partition, that make no differences to those pauses.
Yep will check last snoopy.
What i think about now that if 1:1 the same binary give no micropauses from ram: or from ngfs: (and there on beta both ram: and ngfs: are "new filesystems"), but give them on sfs2, then maybe there some emulation involved to make old filesystems works, and that cause little overhead and small delays ?
I also tryed to play with sfs settings of buffers and blocksizes: does not matter what i have for sfs partition, that make no differences to those pauses.