SFS vs NGFS "PROGDIR:/" question

This forum is for general developer support questions.

Re: SFS vs NGFS "PROGDIR:/" question

Postby tonyw » Fri Dec 28, 2018 10:11 am

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
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 1361
Joined: Wed Mar 09, 2011 2:36 pm
Location: Sydney, Australia

Re: SFS vs NGFS "PROGDIR:/" question

Postby kas1e » Fri Dec 28, 2018 12:42 pm

@tony
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:

56080 : Barony.exe : o.k. = [exec] OpenResource("cacheclearu.resource") [4uS]
56081 : Barony.exe : o.k. = [exec] OpenResource("cacheclearu.resource") [2uS]


While didn't have that for SFS.

Is SFS are "cached filesystem", right ?
kas1e
Beta Tester
Beta Tester
 
Posts: 479
Joined: Sat Jun 18, 2011 8:56 am

Re: SFS vs NGFS "PROGDIR:/" question

Postby colinw » Sat Dec 29, 2018 1:11 am

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 agree, it is a bug, I wrote the function and it's not supposed to do that.

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.
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 175
Joined: Mon Aug 15, 2011 10:20 am
Location: Brisbane, QLD. Australia.

Re: SFS vs NGFS "PROGDIR:/" question

Postby tonyw » Sat Dec 29, 2018 7:51 am

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:

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]
...


On NGFS i didn't notice any slowdowns because of this, but on sfs i can notice those micropauses.


Are you sure the GetFilePosition/SetFilePosition calls are causing delays? A couple of microseconds per call sounds OK to me.


The differences between NGFS and SFS in the snoopy logs, is that for NGFS i have from time to time that:

56080 : Barony.exe : o.k. = [exec] OpenResource("cacheclearu.resource") [4uS]
56081 : Barony.exe : o.k. = [exec] OpenResource("cacheclearu.resource") [2uS]


While didn't have that for SFS.

Those calls are not from NGFS. I don't know where they come from.

Is SFS are "cached filesystem", right ?


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.
cheers
tony
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 1361
Joined: Wed Mar 09, 2011 2:36 pm
Location: Sydney, Australia

Re: SFS vs NGFS "PROGDIR:/" question

Postby colinw » Sat Dec 29, 2018 9:13 am

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.
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 175
Joined: Mon Aug 15, 2011 10:20 am
Location: Brisbane, QLD. Australia.

Re: SFS vs NGFS "PROGDIR:/" question

Postby kas1e » Sat Dec 29, 2018 3:02 pm

@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.
kas1e
Beta Tester
Beta Tester
 
Posts: 479
Joined: Sat Jun 18, 2011 8:56 am

Previous

Return to General Developer Support

Who is online

Users browsing this forum: No registered users and 3 guests