search

PiSCSI / piscsi

PiSCSI allows a Raspberry Pi to function as emulated SCSI devices (hard disk, CD-ROM, and others) for vintage SCSI-based computers and devices. This is a fork of the RaSCSI project by GIMONS.
https://piscsi.org
BSD 3-Clause "New" or "Revised" License
545 stars 82 forks source link

raSCSI needs to periodically check disk write cache(s) #335

Open Pacjunk opened 3 years ago

Pacjunk commented 3 years ago

Info

Describe the issue

In my testing I have noticed that raSCSI only flushes the disk cache(s) either when it is full, or at shutdown (thanks to a recent change). This potentially leads to unflushed data sitting in the cache for extended periods when the cache is not full.

The following highlights the issue:

Someone probably needs to check this on a Mac, as I'm surprised this hasn't been noticed before if it occurs there. The unclean shutdown scenario is more common than you would think especially when the raSCSI is wired to the hosts power supply. People would just flick the switch without remembering to shut down the Raspberry pi.

Now the cache is there for performance reasons and it should also not be flushed at random times as it may slow current I/O.

I'm not familiar with the raSCSI code or Pi programming in general, but here is how I see something being implemented:

- Have a counter or register that increments with every I/O. This should not add too much overhead. Lets call it IOCOUNT.
  Doesnt matter if it wraps around.
- Have another variable that records IOCOUNT when the cache is checked. Lets call it IDLECOUNT init to 0.

- Have some process that wakes regularly (e.g. every 5 seconds) and does the following:

    debug("Checking for idle")
    If IOCOUNT = IDLECOUNT then
        ! There have been no I/Os in the last 5 seconds
        debug("Idle detected")
        If the cache is dirty then
            Flush the cache & debug("Cache flushed")
    IDLECOUNT = IOCOUNT

If the system is not idle, then this should not add too much overhead. I suppose it could break if an OS is contantly pinging a disk (e.g. quorum disk). Checking interval may need to be fine tuned in this case.

Another option might be to allow the use of write-through caching. This would probably have a performance hit on slower SD cards, but at least the data would be consistent.

uweseimet commented 2 years ago

@akuker Regarding the performance compared to BlueSCSI, can the RaSCSI hardware be the bottleneck? What is the maximum throughput the RaSCSI hardware can support? (I'm not a hardware expert at all ...)

uweseimet commented 2 years ago

One thing I cannot tell: Is the current caching approach a good one? The code (like everything else in the filesystem-related legacy code) looks rather complicated to me. I/O even for operations natively supported by the OS appears to be wrapped into a lot of custom code.

A very simple general non-caching solution would just take a file, and when SCSI read/write commands are received it would calculate the read/write position based on the sector number and sector size. Then it would fseek() to this position and just read or write. Wouldn't this approach also work for RaSCSI when caching is disabled? Linux woudl still cache in this case, of course. But why is the RaSCSI code for mapping SCSI commands to files this complicated?

Pacjunk commented 2 years ago

A very simple general non-caching solution would just take a file, and when SCSI read/write commands are received it would calculate the read/write position based on the sector number and sector size. Then it would fseek() to this position and just read or write.

Exactly what bluescsi does.

akuker commented 2 years ago

But why is the RaSCSI code for mapping SCSI commands to files this complicated?

I can only speculate.... but it might have been to help with portability. The original version could also build for bare metal. I believe the base library was also used for XM6 emulator (https://archive.org/details/xm-6-pro-68k-web-package.-7z), so there could be some historical reason for the stuff to be there.

It could definitely be streamlined, but there hasn't been a compelling reason (yet)

Pacjunk commented 2 years ago

I have a theory...

I have noticed that it takes a couple of minutes for the 2 drives to show up on the workstation. If mmap maps the file to virtual memory, maybe it is reading the whole file into virtual memory (which takes a long time), and because of the low memory in the pi zerow, you are effectively just moving the file to the page/swap file which is not going to help performance and will actually hurt it due to the pi being starved of memory. The "active" region of a disk is going to be fairly small compared to the size of the disk, so why read the whole thing into virtual memory?

I will test this later on today by presenting one very small drive (which should fit in memory easily) and see if the performance improves.

uweseimet commented 2 years ago

In order to map a file into memory you do not have to read the file. You modify the CPU´s or MMU´s page descriptors in order to map (but not load) the file into memory. (Also see one of my older comments on this.) That's just the way virtual memory works. Either sectors of a partition are mapped this way (swap device, swap partition), or sectors of a file are mapped (swap file). The latter is less efficient. Actual loading of file contents is only required if a page (e.g. part of a file) that is not yet in memory is accessed. As long as there is no access, setting up the descriptor table is sufficient. But even in this case page descriptors have to be set up. The number of page descriptors the CPU can hold in its internal page descriptor cache is limited, and if the number of active descriptors exceeds the entries available in the internal cache, the page descriptors (but not the file) have to be saved/loaded to/from memory, which will slow things down. I guess that mmap() consumes available descriptors, which slows things down. That's similar to having a swap file and using it by accessing memory areas that are swapped out. The less real memory you have, and the less page descriptors the CPU can store internally, the slower things get. And as already mentioned, Linux uses a page size of 4KB, i.e. 4KB have to be loaded and saved even when only a typical 512 bytes sector of an image file is accessed.

Pacjunk commented 2 years ago

Fair enough - yes I checked memory usage and it seems to be normal before connecting it to the machine. I'll see what happens once I run my "benchmark"

Pacjunk commented 2 years ago

That kills that theory! Tried a very small disk, and performance is the same (poor). Going on what you said, Uwe, I decided to copy the entire 200MB disk. Sure enough free memory gradually fell by 200MB, which didn't leave much left on the pi zero!

I then tried to attach another disk, and the rascsi service keeps restarting. It hasn't given back the 200MB of memory, so it is probably having trouble starting up now. I will give it a reboot and see what happens.

Pacjunk commented 2 years ago

Here is an extract from the log. Note that I didn't restart rascsi, it was doing that itself.

Feb 13 12:40:28 raspberrypi RASCSI[577]: [2022-02-13 12:40:28.697] [warning] bool DiskCache::ReadSector(BYTE*, int) track:4011 sector:86 offset:525773824 block:1026902 size:512
Feb 13 12:40:28 raspberrypi RASCSI[577]: [2022-02-13 12:40:28.712] [warning] bool DiskCache::ReadSector(BYTE*, int) track:4006 sector:137 offset:525144576 block:1025673 size:512
Feb 13 12:40:28 raspberrypi RASCSI[577]: [2022-02-13 12:40:28.722] [warning] bool DiskCache::ReadSector(BYTE*, int) track:3 sector:87 offset:437760 block:855 size:512
Feb 13 12:40:28 raspberrypi RASCSI[577]: [2022-02-13 12:40:28.723] [warning] bool DiskCache::ReadSector(BYTE*, int) track:3 sector:88 offset:438272 block:856 size:512
Feb 13 12:40:28 raspberrypi RASCSI[577]: [2022-02-13 12:40:28.732] [warning] bool DiskCache::WriteSector(const BYTE*, int) track:4006 sector:137 offset:525144576 block:1025673 size:512
Feb 13 12:40:28 raspberrypi RASCSI[577]: [2022-02-13 12:40:28.734] [warning] bool DiskCache::ReadSector(BYTE*, int) track:4006 sector:137 offset:525144576 block:1025673 size:512
Feb 13 12:40:34 raspberrypi RASCSI[577]: [2022-02-13 12:40:34.820] [warning] bool DiskCache::ReadSector(BYTE*, int) track:0 sector:1 offset:512 block:1 size:512
Feb 13 12:40:34 raspberrypi systemd[1]: rascsi.service: Main process exited, code=killed, status=11/SEGV
Feb 13 12:40:34 raspberrypi systemd[1]: rascsi.service: Failed with result 'signal'.
Feb 13 12:40:35 raspberrypi systemd[1]: rascsi.service: Service RestartSec=100ms expired, scheduling restart.
Feb 13 12:40:35 raspberrypi systemd[1]: rascsi.service: Scheduled restart job, restart counter is at 2.
Feb 13 12:40:35 raspberrypi systemd[1]: Stopped RaSCSI service.
Feb 13 12:40:35 raspberrypi systemd[1]: Started RaSCSI service.
Feb 13 12:40:35 raspberrypi RASCSI[745]: SCSI Target Emulator RaSCSI(*^..^*) version 22.03 --DEVELOPMENT BUILD-- (Feb 13 2022, 09:37:11)
Feb 13 12:40:35 raspberrypi RASCSI[745]: Powered by XM6 TypeG Technology / Copyright (C) 2016-2020 GIMONS
Feb 13 12:40:35 raspberrypi RASCSI[745]: Copyright (C) 2020-2021 Contributors to the RaSCSI project
Feb 13 12:40:35 raspberrypi RASCSI[745]: Connect type : FULLSPEC
Feb 13 12:40:35 raspberrypi RASCSI[745]: [2022-02-13 12:40:35.319] [info] Set log level to 'info'
Feb 13 12:40:35 raspberrypi RASCSI[745]: [2022-02-13 12:40:35.328] [info] Reserved ID(s) set to 7
Feb 13 12:40:35 raspberrypi RASCSI[745]: [2022-02-13 12:40:35.328] [info] Default image folder set to '/home/pi/images'
Feb 13 12:40:35 raspberrypi RASCSI[745]: [2022-02-13 12:40:35.328] [info] No images currently attached.
Feb 13 12:40:35 raspberrypi RASCSI[745]: No images currently attached.
Feb 13 12:41:20 raspberrypi RASCSI[745]: [2022-02-13 12:41:20.726] [info] Validating: operation=ATTACH, command params='locale=en', 'token=???', device id=2, unit=0, type=SCHD, device params='file=TESTT.hds', vendor='DEC', product='RZ26L    (C) DEC', revision='440C', block size=512
Feb 13 12:41:20 raspberrypi RASCSI[745]: Size: 1050040320
Feb 13 12:41:20 raspberrypi RASCSI[745]: [2022-02-13 12:41:20.732] [info] Executing: operation=ATTACH, command params='locale=en', 'token=???', device id=2, unit=0, type=SCHD, device params='file=TESTT.hds', vendor='DEC', product='RZ26L    (C) DEC', revision='440C', block size=512
Feb 13 12:41:20 raspberrypi RASCSI[745]: Size: 1050040320
Feb 13 12:41:20 raspberrypi RASCSI[745]: [2022-02-13 12:41:20.733] [info] Attached SCHD device, ID 2, unit 0
Feb 13 12:41:34 raspberrypi RASCSI[745]: [2022-02-13 12:41:34.795] [info] Validating: operation=ATTACH, command params='locale=en', 'token=???', device id=3, unit=0, type=SCHD, device params='file=TESTT2.hds', vendor='DEC', product='RZ26L    (C) DEC', revision='440C', block size=512
Feb 13 12:41:34 raspberrypi RASCSI[745]: Size: 1050040320
Feb 13 12:41:34 raspberrypi RASCSI[745]: [2022-02-13 12:41:34.802] [warning] Unabled to memory map file /home/pi/images/TESTT2.hds
Feb 13 12:41:34 raspberrypi RASCSI[745]: [2022-02-13 12:41:34.802] [warning]    Errno:12
Feb 13 12:41:34 raspberrypi RASCSI[745]: [2022-02-13 12:41:34.802] [info] Executing: operation=ATTACH, command params='locale=en', 'token=???', device id=3, unit=0, type=SCHD, device params='file=TESTT2.hds', vendor='DEC', product='RZ26L    (C) DEC', revision='440C', block size=512
Feb 13 12:41:34 raspberrypi RASCSI[745]: Size: 1050040320
Feb 13 12:41:34 raspberrypi RASCSI[745]: [2022-02-13 12:41:34.803] [warning] Unabled to memory map file /home/pi/images/TESTT2.hds
Feb 13 12:41:34 raspberrypi RASCSI[745]: [2022-02-13 12:41:34.804] [warning]    Errno:12
Feb 13 12:41:34 raspberrypi RASCSI[745]: [2022-02-13 12:41:34.804] [info] Attached SCHD device, ID 3, unit 0
Feb 13 12:41:35 raspberrypi RASCSI[745]: [2022-02-13 12:41:35.633] [warning] bool DiskCache::ReadSector(BYTE*, int) track:0 sector:1 offset:512 block:1 size:512
Feb 13 12:41:35 raspberrypi systemd[1]: rascsi.service: Main process exited, code=killed, status=11/SEGV
Feb 13 12:41:35 raspberrypi systemd[1]: rascsi.service: Failed with result 'signal'.
Feb 13 12:41:35 raspberrypi systemd[1]: rascsi.service: Service RestartSec=100ms expired, scheduling restart.
Feb 13 12:41:35 raspberrypi systemd[1]: rascsi.service: Scheduled restart job, restart counter is at 3.
Feb 13 12:41:35 raspberrypi systemd[1]: Stopped RaSCSI service.
Feb 13 12:41:36 raspberrypi systemd[1]: Started RaSCSI service.
Feb 13 12:41:36 raspberrypi RASCSI[768]: SCSI Target Emulator RaSCSI(*^..^*) version 22.03 --DEVELOPMENT BUILD-- (Feb 13 2022, 09:37:11)
Feb 13 12:41:36 raspberrypi RASCSI[768]: Powered by XM6 TypeG Technology / Copyright (C) 2016-2020 GIMONS
Feb 13 12:41:36 raspberrypi RASCSI[768]: Copyright (C) 2020-2021 Contributors to the RaSCSI project
Feb 13 12:41:36 raspberrypi RASCSI[768]: Connect type : FULLSPEC
Feb 13 12:41:36 raspberrypi RASCSI[768]: [2022-02-13 12:41:36.171] [info] Set log level to 'info'
Feb 13 12:41:36 raspberrypi RASCSI[768]: [2022-02-13 12:41:36.180] [info] Reserved ID(s) set to 7
Feb 13 12:41:36 raspberrypi RASCSI[768]: [2022-02-13 12:41:36.180] [info] Default image folder set to '/home/pi/images'
Feb 13 12:41:36 raspberrypi RASCSI[768]: [2022-02-13 12:41:36.180] [info] No images currently attached.
Feb 13 12:41:36 raspberrypi RASCSI[768]: No images currently attached.
Feb 13 12:42:14 raspberrypi RASCSI[768]: [2022-02-13 12:42:14.125] [info] Validating: operation=ATTACH, command params='locale=en', 'token=???', device id=2, unit=0, type=SCHD, device params='file=TESTT.hds', vendor='DEC', product='RZ26L    (C) DEC', revision='440C', block size=512
Feb 13 12:42:14 raspberrypi RASCSI[768]: Size: 1050040320
Feb 13 12:42:14 raspberrypi RASCSI[768]: [2022-02-13 12:42:14.135] [info] Executing: operation=ATTACH, command params='locale=en', 'token=???', device id=2, unit=0, type=SCHD, device params='file=TESTT.hds', vendor='DEC', product='RZ26L    (C) DEC', revision='440C', block size=512
Feb 13 12:42:14 raspberrypi RASCSI[768]: Size: 1050040320
Feb 13 12:42:14 raspberrypi RASCSI[768]: [2022-02-13 12:42:14.136] [info] Attached SCHD device, ID 2, unit 0
Feb 13 12:42:39 raspberrypi RASCSI[768]: [2022-02-13 12:42:39.926] [warning] bool DiskCache::ReadSector(BYTE*, int) track:0 sector:6 offset:3072 block:6 size:512
Feb 13 12:42:39 raspberrypi RASCSI[768]: [2022-02-13 12:42:39.927] [warning] bool DiskCache::ReadSector(BYTE*, int) track:0 sector:7 offset:3584 block:7 size:512
Feb 13 12:42:39 raspberrypi RASCSI[768]: [2022-02-13 12:42:39.928] [warning] bool DiskCache::ReadSector(BYTE*, int) track:0 sector:8 offset:4096 block:8 size:512
Feb 13 12:43:10 raspberrypi RASCSI[768]: [2022-02-13 12:43:10.989] [info] Validating: operation=ATTACH, command params='locale=en', 'token=???', device id=4, unit=0, type=SCHD, device params='file=TESTT2.hds', vendor='DEC', product='RZ26L    (C) DEC', revision='440C', block size=512
Feb 13 12:43:11 raspberrypi RASCSI[768]: Size: 1050040320
Feb 13 12:43:11 raspberrypi RASCSI[768]: [2022-02-13 12:43:10.994] [warning] Unabled to memory map file /home/pi/images/TESTT2.hds
Feb 13 12:43:11 raspberrypi RASCSI[768]: [2022-02-13 12:43:10.994] [warning]    Errno:12
Feb 13 12:43:11 raspberrypi RASCSI[768]: [2022-02-13 12:43:10.994] [info] Executing: operation=ATTACH, command params='locale=en', 'token=???', device id=4, unit=0, type=SCHD, device params='file=TESTT2.hds', vendor='DEC', product='RZ26L    (C) DEC', revision='440C', block size=512
Feb 13 12:43:11 raspberrypi RASCSI[768]: Size: 1050040320
Feb 13 12:43:11 raspberrypi RASCSI[768]: [2022-02-13 12:43:10.995] [warning] Unabled to memory map file /home/pi/images/TESTT2.hds
Feb 13 12:43:11 raspberrypi RASCSI[768]: [2022-02-13 12:43:10.995] [warning]    Errno:12
Feb 13 12:43:11 raspberrypi RASCSI[768]: [2022-02-13 12:43:10.996] [info] Attached SCHD device, ID 4, unit 0
Feb 13 12:43:37 raspberrypi RASCSI[768]: [2022-02-13 12:43:37.498] [warning] bool DiskCache::ReadSector(BYTE*, int) track:0 sector:1 offset:512 block:1 size:512
Feb 13 12:43:37 raspberrypi systemd[1]: rascsi.service: Main process exited, code=killed, status=11/SEGV
Feb 13 12:43:37 raspberrypi systemd[1]: rascsi.service: Failed with result 'signal'.
Feb 13 12:43:37 raspberrypi systemd[1]: rascsi.service: Service RestartSec=100ms expired, scheduling restart.
Feb 13 12:43:37 raspberrypi systemd[1]: rascsi.service: Scheduled restart job, restart counter is at 4.
Feb 13 12:43:37 raspberrypi systemd[1]: Stopped RaSCSI service.
Feb 13 12:43:37 raspberrypi systemd[1]: Started RaSCSI service.
Feb 13 12:43:37 raspberrypi RASCSI[807]: SCSI Target Emulator RaSCSI(*^..^*) version 22.03 --DEVELOPMENT BUILD-- (Feb 13 2022, 09:37:11)
Feb 13 12:43:37 raspberrypi RASCSI[807]: Powered by XM6 TypeG Technology / Copyright (C) 2016-2020 GIMONS
Feb 13 12:43:37 raspberrypi RASCSI[807]: Copyright (C) 2020-2021 Contributors to the RaSCSI project
Feb 13 12:43:37 raspberrypi RASCSI[807]: Connect type : FULLSPEC
Feb 13 12:43:37 raspberrypi RASCSI[807]: [2022-02-13 12:43:37.803] [info] Set log level to 'info'
Feb 13 12:43:37 raspberrypi RASCSI[807]: [2022-02-13 12:43:37.811] [info] Reserved ID(s) set to 7
Feb 13 12:43:37 raspberrypi RASCSI[807]: [2022-02-13 12:43:37.811] [info] Default image folder set to '/home/pi/images'
Feb 13 12:43:37 raspberrypi RASCSI[807]: [2022-02-13 12:43:37.812] [info] No images currently attached.
Feb 13 12:43:37 raspberrypi RASCSI[807]: No images currently attached.
Feb 13 12:49:47 raspberrypi rngd[320]: stats: bits received from HRNG source: 80064
Feb 13 12:49:47 raspberrypi rngd[320]: stats: bits sent to kernel pool: 33824
Feb 13 12:49:47 raspberrypi rngd[320]: stats: entropy added to kernel pool: 33824
Feb 13 12:49:47 raspberrypi rngd[320]: stats: FIPS 140-2 successes: 4
Feb 13 12:49:47 raspberrypi rngd[320]: stats: FIPS 140-2 failures: 0
Feb 13 12:49:47 raspberrypi rngd[320]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Feb 13 12:49:47 raspberrypi rngd[320]: stats: FIPS 140-2(2001-10-10) Poker: 0
Feb 13 12:49:47 raspberrypi rngd[320]: stats: FIPS 140-2(2001-10-10) Runs: 0
Feb 13 12:49:47 raspberrypi rngd[320]: stats: FIPS 140-2(2001-10-10) Long run: 0
Feb 13 12:49:47 raspberrypi rngd[320]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Feb 13 12:49:47 raspberrypi rngd[320]: stats: HRNG source speed: (min=82.557; avg=123.922; max=276.682)Kibits/s
Feb 13 12:49:47 raspberrypi rngd[320]: stats: FIPS tests speed: (min=985.233; avg=1927.775; max=9131.019)Kibits/s
Feb 13 12:49:47 raspberrypi rngd[320]: stats: Lowest ready-buffers level: 2
Feb 13 12:49:47 raspberrypi rngd[320]: stats: Entropy starvations: 0
Feb 13 12:49:47 raspberrypi rngd[320]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Pacjunk commented 2 years ago

mmm, can't mount 2 x 1GB volumes at the same time. First one is OK, but crashes on 2nd one (this is the cause of the above log). I have created 2 x 200MB disks, and I can mount these at the same time. Did a test copying to these and it stops using memory when the free memory gets below 10% (about 43MB on the pi zero).

Maybe this mmap method is a bit unreliable, and a potential memory hog.

@akuker How hard is it to replace the RaSCSI caching with just plain file I/O, and not use mmap?

akuker commented 2 years ago

It would be pretty easy, actually. I can work on that next.

For now, I noticed that we never actually gave RaSCSI a high priority in the system. I'm assuming that for most people, RaSCSI is the most important (as far as real-time) process. Using the 'nice' utility to give rascsi a higher priority, the performance is as good as the original RAM cache approach.

@Pacjunk - could you try out the latest change in this file? https://github.com/akuker/RASCSI/blob/bug_335_cache_fix/src/raspberrypi/os_integration/rascsi.service

(That file needs to be copied to /etc/systemd/system. Then run sudo systemctl daemon-reload)

image

Pacjunk commented 2 years ago

No real difference, maybe slightly slower. I notice that the priority for the rascsi process was marked as "rt" before the change was made.

Also, on the crash noted above, I cannot mount a single 2GB image (which works fine on other branches). Smaller ones are fine.

akuker commented 2 years ago

Testing out the fopen/fseek approach right now :]

akuker commented 2 years ago

@Pacjunk - An updated version using posix file i/o calls is available on the bug_335_cache_fix_selectable branch. I created a new branch so that I didn't mess up the original mmap version. (not sure if I'll ever need to go back to it, but holding onto it for now)

Feel free to give this a try! If you want to switch between versions, update file_access/file_access_factory.cpp to change current_access_type.

Note: you'll need to clean your checkout, since I've moved some files around.

Pacjunk commented 2 years ago

OK, rebuilding now. Thanks

Pacjunk commented 2 years ago

OK, with your new code, I'm getting 298KB/sec or 292KB with the dirty parameters set down. I also no longer have issues with 2GB+ images crashing the service. BTW I'm only getting ~330KB to a real HDD, so performance is getting up there. I probably should run some tests on the Alpha which has much faster disks/cpu/ram etc.

uweseimet commented 2 years ago

Quite funny: While implementing the SCSI printer device I am stumbling upon code where the current caching approach causes issues: Caching only supports multiples of 512 byte blocks, i.e. if a data chunk is not a multiple of 512 bytes neither reading nor writing will work with the current code. This is not just relevant for the printer device, but also for improving the incomplete READ/WRITE LONG implementation, which also deals with arbitrary data sizes. I should rather say that's tragic, not funny ;-).

beetle060 commented 2 years ago

Hello, i'm running into problems connected to this issue.

My RaSCSI is connected to the "CSS BlackBox", a SCSI interface for the Atari 8-Bit series. I can configure a HDD image and configure the BlackBox to use it. First i need to perform a low level format, then create partitions, and finally initialize those partitions in order to use them with the different DOS versions of the XL/XE. This is all very low level, and no hard disk driver suite like Uwe's HDDriver exists. There is a PARK.COM program, but it doesn't seem to motivate the RaSCSI to flush the cache, so most access to the RaSCSI HDD image is lost after power off. Its very cumbersome to create a network, get both, Pi and a PC connected and then shut down the pi properly before switching off the Atari. Working with these old machines involves often power cycling. I'm not sure if i overlooked a solution i could use. Performance is less of an issue, the Atari 8 bit can hardly put more than 100kByte/s over the parallel bus.

Perhaps someone could be so kind and explain me how to switch the caching off.

Thank you for reading Stefan

uweseimet commented 2 years ago

@beetle060 Can you please check which SCSI commands PARK.COM sends? In order to do this start rascsi with the "-L trace" option. When attaching the log please only attach the part of the logfile that contains the commands sent by PARK.COM. If possible, use the current develop branch for testing. If this is not possible please use release 22.08.01. Which version is the one you have been using when running into your problem?

When you shut down rascsi or the Pi (either with rasctl, the web UI or the RaSCSI control app) all caches are flushed automatically.

There is no way to switch off the cache. IMHO the current cache implementation is not useful, and it even prevents progress on some open tickets.

beetle060 commented 2 years ago

I am new to github and to the project, i just downloaded the readily configured Pi image. Not sure which version it runs. I only used the WebUI to configure a disk image, and i configured the Pi to have ssh access enabled so i can login to the shell from my PC. Maybe i can configure serial login from my Atari XL to Pi via a RS232-USB converter. I need to figure out how to start RaSCSI with a commandline option and where to find the logs. I can look into it tomorrow morning.

PS: i just found out about Rascsi-Control and bought it. that should make life easier already. But still, a SCSI Harddisk will not keep several tracks of data in the cache for longer periods of time - so shouldn't RaSCSI

uweseimet commented 2 years ago

@beetle060 If you still have issues with the latest release and when using the regular RaSCSi/Pi shutdown offered by RaSCSI Control, in order to further investigate I would need the rascsi logfile. You can set the log level to "trace" within RaSCSI Control app, for instance.

beetle060 commented 2 years ago

Where do i find the rascsi log file? Seems to be so obvious that i cannot find any info, even on the wiki. I spent the last hour looking for it... The log level i set to "trace" already. I want to know which commands "PARK.COM" sends.

uweseimet commented 2 years ago

@rdmark Do you know the default logfile location on the Pi? I always use the console log.

@beetle060 I assume it is somewhere in /var/log.

beetle060 commented 2 years ago

OK, found it. I loaded DOS and entered the directory with PARK.COM. Then i switched log level to "trace" and loaded PARK.COM which then parked the Drive. I pastebin'ed the log at https://pastebin.com/3Lp8bVp4 or should i just drop it here?

PS: the emulated HDD is 20MB Miniscribe from the existing drives library. My Atari detected a HDD "Miniscribe" with 8 heads, 205 cylindres and 82006 sectors .

uweseimet commented 2 years ago

@beetle060 I suggest that you create a new github issue and then add the logfile and the issue description there, because this is a separate issue, which is not related to the current ticket. We should not mix unrelated issues.

beetle060 commented 2 years ago

OK, thanks for the advice

kirbyfrugia commented 1 year ago

Any update on this issue? I have bumped into this a couple times when forgetting to shutdown my pi cleanly.

akuker commented 1 year ago

Unfortunately, no. I will not be able to address it soon. Hopefully one of the other devs can pick it up.