Thanks. But I'm specifically *not* talking about database apps, I'm
talking about non-database applications written in languages that
don't even have a concept of fsync. I understand that PostgreSQL would
be perfectly fine on pretty much any unix filesystem short of tmpfs.
But PostgreSQL is just a small part of my mixed workloads. I wish
everything I had were PostgreSQL. But I have to deal with reality. My
only reasonable migration path for getting everything backed by a
database is to upgrade to the latest version of our software, replace
all the Linux workstations with Windows, replace the Linux servers
with Windows Server 2008 or later, and install Microsoft SQL Server at
all locations. I'm sticking with the current Cobol app which is quite
stable and reliable when running on ext3. Especially as I keep hearing
that the newer Windows-only version doesn't work particularly well.
On Tue, Jun 11, 2013 at 12:31 PM, Ric Wheeler <rwheeler@xxxxxxxxxx> wrote:
> On 06/11/2013 01:27 PM, Stefan Ring wrote:
>>> Let's take a simple example - a database app that does say 30
>>> In your example, you are extremely likely to lose up to just shy of 5
>>> seconds of "committed" data - way over 100 transactions! That can be
>>> *really* serious amounts of data and translate into large financial loss.
>> Every database software will do the flushing correctly.
> Stefan, you are making my point because every database will do the right
> thing, it won't rely on ext3's magic every 5 second fsync :)
>>> In a second example, let's say you are copying data to disk (say a movie)
>>> a rate of 50 MB/second. When the power cut hits at just the wrong time,
>>> will have lost a large chunk of that data that has been "written" to disk
>>> (over 200MB).
>> But why would anyone care about that? I know that the system went down
>> while copying this large movie, so I'll just copy it again.