Re: [sqlite] Potential bug: Database on gvfs mount cannot be committed to

[Simon Slavin]

On 19 Sep 2016, at 2:52am, Keith Medcalf  wrote:

> That is to say there is no difference between a block device (such as a 
> physical hard disk) attached to the computer via a 1 foot SCSI cable and an 
> iSCSI LUN where the iSCSI block device is located on a different plant, other 
> than the latency of the command/response.  In both cases you are using a 
> "Local" filesystem.
> 
> This is vastly different from mounting a "remote shared filesystem" from 
> another computer, whether that computer is located in the next rack slot or 
> located on another planet.

And it's going to get worse since the next generation is 'cloud storage' which 
looks like what you've called "remote shared filesystem" but has no fixed 
hardware.  It can be addressed using a network file system (SMB2 / CIFS / NFS) 
but the programmer will have no idea whether their data ends up on a rotating 
disk next door or spread over six SSDs on four continents.  So on top of the 
current problems it exhibits unpredictable timing problems.

We just have to pray that the network file system implements locking properly.  
Which SMB2 does allow, but I have no idea whether any drivers actually do it 
correctly.

Hmm.  Earlier this year Apple announced it's working a new file system, 
designed for the modern age with some pretty neat abilities.  It's suited to 
everything from Smart Cards to snapshottable virtual partitions in the cloud.  
Apple said it will release open source drivers and make the whole thing 
unencumbered by patents.  Now if it could just do the same thing with an API 
which implements locking correctly ...

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Potential bug: Database on gvfs mount cannot be committed to

[Keith Medcalf]

No database server product of which I am aware will "work" properly when the 
database resides on a remote filesystem.  There is a *vast* difference between 
a "remote file system" and a "local file system on a remote block device".

There is no difference between a "remote block device" known as a Hard Disk 
that is remotely attached via a SCSI/SATA/PATA/IDE/MDM cable on which the Local 
Computer creates a local filesystem for its own exclusive use, and a "remote 
block device" that is attached via iSCSI or Fiber Channel on which the Local 
Computer creates a local filesystem for its own exclusive use, except for the 
length of the cable connecting the "Local Computer" to the block storage device.

That is to say there is no difference between a block device (such as a 
physical hard disk) attached to the computer via a 1 foot SCSI cable and an 
iSCSI LUN where the iSCSI block device is located on a different plant, other 
than the latency of the command/response.  In both cases you are using a 
"Local" filesystem.

This is vastly different from mounting a "remote shared filesystem" from 
another computer, whether that computer is located in the next rack slot or 
located on another planet.

The confusion stems from the ill-advised usage of the inaccurate term "Network 
Attached Storage" by the ill-educated to refer to both "Remote Block Storage 
with a Local Filesystem" and "Remote Shared Filesystem", and the propensity of 
(some) of those hearing (or reading) the terms to make inappropriate 
assumptions about the meaning of the terms without understanding the 
consequences of those assumptions.

Practically every device connected to the Internet qualifies as "Network 
Attached Storage" and from that perspective, the Internet is just a great big 
"Storage Area Network".

Neither of those terms have anything to do with whether the filesystem is local 
or remote.  And the ability to create a "snapshot" does not require a Remote 
File System, nor does it require a Local File System.  In fact, it is 
completely independent of where the Filesystem is locatedhow it is attached, or 
the physical storage back-end.

> * R. Smith:
 
> > Enterprise DBs have servers on the same machine as the Files they
> > access, they do not actually use the network file-system to access the
> > DB data-files over the network from multiple clients, or even servers
> > (unless the DBs are partitioned so and ONLY accessed by the single
> > process so locking is permanent and moot).
 
> Deployments vary considerably.  A lot of enterprises use snapshotable
> storage for databases as well, just as an option in case upgrades need
> to be rolled back.




___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Potential bug: Database on gvfs mount cannot be committed to

[Stephen Chrzanowski]

"snapshotable" or not, DBs are accessed from the local file system, not
from a network where another OS has control of the file system.

On Sun, Sep 18, 2016 at 10:16 AM, Florian Weimer  wrote:

> * R. Smith:
>
> > Enterprise DBs have servers on the same machine as the Files they
> > access, they do not actually use the network file-system to access the
> > DB data-files over the network from multiple clients, or even servers
> > (unless the DBs are partitioned so and ONLY accessed by the single
> > process so locking is permanent and moot).
>
> Deployments vary considerably.  A lot of enterprises use snapshotable
> storage for databases as well, just as an option in case upgrades need
> to be rolled back.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Potential bug: Database on gvfs mount cannot be committed to

[Florian Weimer]

* R. Smith:

> Enterprise DBs have servers on the same machine as the Files they
> access, they do not actually use the network file-system to access the
> DB data-files over the network from multiple clients, or even servers
> (unless the DBs are partitioned so and ONLY accessed by the single
> process so locking is permanent and moot).

Deployments vary considerably.  A lot of enterprises use snapshotable
storage for databases as well, just as an option in case upgrades need
to be rolled back.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users