|
Notes |
|
|
|
ok, firstly, the lack of an m directory was fine. The cache never tried to create one! all the metadata filers were less than a kilobyte long and were therefore being stored in the block files.
Which is where we actually hit the issue.
these three lines from the log tell me what the issue is:
content/fs_backing_store.c set_store_entry 933: url:http://www.google.co.uk/favicon.ico
first attempt to store a data object
content/fs_backing_store.c store_open 1058: opening PROGDIR:Users/chris/Cache/dblk/A
which succeeded at opening the block file
content/fs_backing_store.c store_write_block 1609: Write failed -1 of 5430 bytes from 0x54bf6420 at 0x2000 block 1 errno 29
from the ppc sys/errno.h
#define ESPIPE 29 /* Illegal seek */
so errno 29 is telling us that the pwrite operation was trying to seek to offset 0x2000 (8k) into the block file and write the 5430 bytes of data and got told it could not seek there.
On other operating systems seeking past the end of a file opened for writing simply extends the file. Is this the not case on amigaos 4?
|
|
|
|
|
|
|
|
|
ok so, how about an amigaos wrapper that tries the seek and if it gets errno 29 calls the ChangeFileSize() to extend to the offset, retries the lseek and then does a write.
I already added a wrapper for RISC OS in utils/config.h and utils/utils.c so extending it for amigaos would seem relatively straightforward |
|
|
|
|
|
That sounds like it should work. |
|
|
|
|
ok added a universal pread/pwrite implementation to libnsutils as it was horribly hacky and removed the compat cruft from NetSurf itself.
The new implementation of pwrite *should* work on amigaos now. Please can you start from a clean cache again and post the log to the bug so I can check? |
|
|
|
|
|
Attached. The mblk and dblk 'A' file now has size, so looks good. |
|
|
|
|
phew. all looks good and the 1.5megabytes/sec overall write rate looks a lot healthier than previous scheme.
Thanks for your patience and testing, sorry we had a bit of a rough start. I do hope this improves things for you though please let me know on list either way. |
|
|
|
|
|
Confirmed resolved in 3.4 release |
|
ns.log.gz (111,799) 2015-04-01 18:29