Info

• Which version of Pi are you using: ZeroW
• Which github revision of software: develop
• Which board version: FULLSPEC
• Which computer is the RaSCSI connected to: AlphaServer 1000 & VAXstation 3100.

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:

• Attach a drive, and mount in your OS
• Open a text file on that drive and write a few line of text
• Close the file
• Dismount the drive from the OS so that the OS flushes its cache!
• Wait 60 seconds or more just to be sure!
• Disconnect power to the Rapberry Pi (do not shut down)
• Reboot, Reattach and remount the drive in your OS
• The text file is not there!

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.