On 13 Nov 2015, at 6:46pm, A. Mannini <alessandro.mannini at esod.it> wrote:
> 1) is there a list of FS where SQLite works fine?
It's not usually the FS which is causing the problem. When your application
tells the OS to write to a remote disk ...
program calls OS API to write to a file
OS calls Network FS on client
Network Filing System communicates across the network
NFS on server calls FS
FS calls storage driver
storage driver talks to hardware
hardware performs the write
hardware reads the sector just written
hardware checks what was read matches what it was told to write
hardware returns success/error code to storage driver
storage driver returns success/error code to file system
file system returns success/error code to server-side NFS
Network Filing System communicates across the network
Network FS on client returns success/error code to the OS
OS API returns success/error code to the program
program correctly handles success/error
(Above is simplified. For example, any stage might try again if it gets an
error.)
Only in server-range setups (expensive, slow) is this correctly implemented.
It takes a lot of time (a millisecond or two for each call) to do it right. If
this setup was used for your desktop computer you'd be down to three or four
characters a second in Word. I've set computers up this way for demonstrations
and they are ridiculously slow and annoying to use. Like 25 minutes to from
power-on to being able to type in Word.
In standard desktop setups the pause for the check is skipped, either by the
hardware (check your jumper settings) or in the storage driver. Instead of
waiting for the check, it receives the command, returns "Command executed
without error." and /then/ passes the command along to the lower level. Much
faster.
As you can see this occurs below file system level and is dependent on your
hard drive and its driver, the DIP (jumper) settings set on your hard drive,
and the mode your driver is loaded in. Worse still, manufacturers change the
specification of a drive and what the jumpers mean without changing the model
name. And it can happen even if both your FS and NFS are bugless. The whole
thing's a nightmare.
> 2) why there are SERVERLESS database (MS Access or VistaDB) that works
> without FS restrictions?
Both have similar problems. They all suffer from rare failures. You can use
any of these databases for a year without problems and then get database
corruption for no obvious reason.
Simon.
