Hello, Pavel!

This is a well-known ambush in Linux + Firebird, related with fact that
server does not release database until last user disconnected and, in the
same time, Linux allows you to delete and "replace" file.
I am not sure what exact versions of FB and Linux suffer from this but I
suppose that all.

Usually it is happened after backup and restore cycle with all-time
connected users.

I am confused because you said it is hard to reproduce.
Unfortunately I have no Linux box available now, but I can give you test
case plan.

1) connect to employee.fdb using isql
2) Simultaneously perform backup of this database and then immediately
restore it to the same location using -R switch (may be, manually delete
employee.fdb)
3) add something BLBLBLA into any table of employee.fdb
4) Disconnect from employee.fdb in isql
5) reconnect to employee.fdb and see missed BLBLBLA

May be I missed something...
Anyway I will perform such test when Linux box will be available.

Sincerely yours,
Alexey Kovyazin
IBSurgeon
www.ibsurgeon.com

----- Original Message -----
From: Pavel Cisar
To: firebird-support@yahoogroups.com
Cc: firebird-devel@...
Sent: Tuesday, January 18, 2005 6:08 PM
Subject: [firebird-support] "Mysterious" data loss


Hi all,

I would like hear from anyone who have ever experienced a "mysterious"
data loss from Firebird/InterBase database on Linux. I've heard about
two such incidents before and now I've got another fresh one. It's rare,
but very real and serious phenomenon, and I would like find out the
conditions that lead to it, so I would appreciate any information about
its other occurrences in the field.

Problem description:

Data mysteriously vanish from database. It could be any data, or whole
tables etc. when database structure was altered, but database is not
damaged or corrupted in any way. From user's point, it looks like
database was suddenly reverted to some previous state (a time warp in
past), like an accidental database restore, although it didn't happen
(and from the info I've collected so far, it couldn't be this case,
although I haven't a strong evidence). This "old state" could vary from
hours to several days.

Reports that I've collected so far indicate, that this problem depends
or may depend on:

- Linux. reported on 2.4 kernel, so far no reports with other kernels
- SuperServer (no reports involving Classic)
- forced writes OFF
- the "time warp" happens when FB is restarted, or all users are
detached from the database (db is closed by server).

There is a *strong suspicion*, that this issue is related to cases, when
database is copied at OS level (cp) while opened/used by Firebird. But
due to delayed nature of this issue, I haven't any evidence of it, and
it's not easily reproducible that way (may depend on other unknown
factors). Although I haven't a strong evidence, the database is very
likely reverted to the state in the time when copy was made.

My personal opinion for now is that this is an unfortunate interaction
between FB server and OS (file cache, software raid, whatever) that
results in unsaved (or overwritten by older version) header page/tips.
Some sort of hiccup at OS file level when live db is copied.

Note for Firebird core developers:
Although I think that this isn't a Firebird bug or fault, Firebird
should prevent such "accidents" whatever the cause really is. It seems
that we have similar problem on Linux like we have on Windows file
cache. Because this problem is real and very dangerous for end users, it
would be nice if core engine Linux developers would seriously take a
look at this issue.

Best regards
Pavel Cisar



Yahoo! Groups Links

To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

To unsubscribe from this group, send an email to:
firebird-support-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.