Re: [sqlite] Why would batched write operations NOT be faster than individual ones

>And as far as I know, even the most expensive hardware RAID controllers >and disks do not yet support multi-disk transactions, so your reference >to not-yet existing hardware is moot. They all do, unless the I/O was designed by a moron. Of course, morons are the most plentiful element in the

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

Hi, Von: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] > At 21:35 03/03/2014, you wrote: > ´¯¯¯ > >RAID3-4-5 was great when disks were expensive, in 80's an 90's. Now > >not. A minimal RAID5 needs 3 disks. A minimal RAID10 4. An enterprise > >disk SAS 15Krpm 146 GB 6G

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

>Another way to bust your data is to rely on RAID 5 or 6 or similar, at >least if the software does not take special care. > >When those mechanisms, updating a block always results in at least 2 disk >writes: The data block and the checksum block. There's a small time >window where only one of

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

At 21:35 03/03/2014, you wrote: ´¯¯¯ RAID3-4-5 was great when disks were expensive, in 80's an 90's. Now not. A minimal RAID5 needs 3 disks. A minimal RAID10 4. An enterprise disk SAS 15Krpm 146 GB 6G is $350, and a not enterprise grade cheaper and bigger. Now RAID1E and RAID10E give more

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

On Mon, 03 Mar 2014 17:36:10 +0100 Jean-Christophe Deschamps wrote: > > >It's how RAID5 works. Check this page docs http://baarf.com/ about > >it. > > This is utter BS. No. > Serious RAID controllers perform parallel I/O on as many drives that > are making up a given

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/14 03:00, Simon Slavin wrote: > What the heck ? Is this a particular implementation of RAID ... The technical term is "write hole" and can occur at many RAID levels: http://www.raid-recovery-guide.com/raid5-write-hole.aspx You can

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

It's how RAID5 works. Check this page docs http://baarf.com/ about it. This is utter BS. Serious RAID controllers perform parallel I/O on as many drives that are making up a given array. Of course I'm talking of SAS drives here with battery backed-up controller. Kid sister RAID5-6

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

On Mon, 3 Mar 2014 11:00:47 + Simon Slavin wrote: > What the heck ? Is this a particular implementation of RAID or a > conceptual problem with how RAID is designed to work ? It sounds > like a bug in one particular model rather than a general problem with > how RAID

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

Hi, Von: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] > On 3 Mar 2014, at 8:18am, Markus Schaber wrote: > > Another way to bust your data is to rely on RAID 5 or 6 or similar, at > > least if the software does not take special care. > > > > When

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

On 3 Mar 2014, at 8:18am, Markus Schaber wrote: > Another way to bust your data is to rely on RAID 5 or 6 or similar, at least > if the software does not take special care. > > When those mechanisms, updating a block always results in at least 2 disk > writes: The data

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

Hi, sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] > On 3 Mar 2014, at 3:41am, romtek wrote: > [...] > > Here's a SQLite engineer writing about the same thing: section 3.1 of > > > > Your disk hardware,

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

On 3 Mar 2014, at 3:41am, romtek wrote: > Thanks, Simon. Interestingly, for this server, disk operations aren't > particularly fast. One SQLite write op takes about 4 times longer than on a > HostGator server. That supports the idea that storage is simulated (or

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

Thanks, Simon. Interestingly, for this server, disk operations aren't particularly fast. One SQLite write op takes about 4 times longer than on a HostGator server. I wonder if what I/you described also means that this file system isn't likely to support file locks needed for SQLite to control

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

On 3 Mar 2014, at 2:14am, romtek wrote: > On one of my hosting servers (this one is a VPS), a bunch of write > operations take practically the same amount of time when they are performed > individually as when they are performed as one explicit transaction. I've > varied the

Re: [sqlite] Why would batched write operations NOT be faster than individual ones

In case this gives somebody a clue, the server in question is on http://vps.net/. On Sun, Mar 2, 2014 at 8:14 PM, romtek wrote: > Hi, > > On one of my hosting servers (this one is a VPS), a bunch of write > operations take practically the same amount of time when they are

[sqlite] Why would batched write operations NOT be faster than individual ones

Hi, On one of my hosting servers (this one is a VPS), a bunch of write operations take practically the same amount of time when they are performed individually as when they are performed as one explicit transaction. I've varied the number of ops up to 200 -- with the similar results. Why is that?