Re: [sqlite] Potential bug: Database on gvfs mount cannot be committed to
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
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
"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
* 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