Database Disk Full

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Database Disk Full

Drew, Stephen
Hello,
 
In sqlite3OsWrite function (in os_win.c)  the following code exists:
 
  while( amt>0 && (rc = WriteFile(id->h, pBuf, amt, &wrote, 0))!=0 &&
wrote>0 ){

    amt -= wrote;

    pBuf = &((char*)pBuf)[wrote];

  }

  if( !rc || amt>(int)wrote ){

    return SQLITE_FULL;

  }

Is this really a valid occasion to return SQLITE_FULL?   Surely
WriteFile Win32 API call can fail to write a full for a plethora of
reasons, or am I missing something?

Many thanks in advance

Regards,

Steve

Reply | Threaded
Open this post in threaded view
|

Re: Database Disk Full

D. Richard Hipp
"Drew, Stephen" <[hidden email]> wrote:

> Hello,
>  
> In sqlite3OsWrite function (in os_win.c)  the following code exists:
>  
>   while( amt>0 && (rc = WriteFile(id->h, pBuf, amt, &wrote, 0))!=0 &&
> wrote>0 ){
>
>     amt -= wrote;
>
>     pBuf = &((char*)pBuf)[wrote];
>
>   }
>
>   if( !rc || amt>(int)wrote ){
>
>     return SQLITE_FULL;
>
>   }
>
> Is this really a valid occasion to return SQLITE_FULL?

What error code would you suggest as an alternative?
--
D. Richard Hipp   <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

RE: Database Disk Full

Drew, Stephen
In reply to this post by Drew, Stephen
Hello,

Thanks for the swift response.

Hmm I don't know to be honest, something generic perhaps like a failure
to write...

It's just a little bit misleading if you're not familiar with the
circumstances it's raised in... I've had some confused colleagues
wondering why their 100kb DB on a disk with 15gb free would be out of
space :)

It's nothing urgent for me, I will alter the error message I return to
offer more suggestions as to the cause, but given in Windows we can use
GetLastError() and format an error message, this information would no
doubt be of use to people in diagnosing why the file write failed.

Many thanks, and keep up the great work!

Steve

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: 10 February 2006 17:01
To: [hidden email]
Subject: Re: [sqlite] Database Disk Full

"Drew, Stephen" <[hidden email]> wrote:

> Hello,
>  
> In sqlite3OsWrite function (in os_win.c)  the following code exists:
>  
>   while( amt>0 && (rc = WriteFile(id->h, pBuf, amt, &wrote, 0))!=0 &&
> wrote>0 ){
>
>     amt -= wrote;
>
>     pBuf = &((char*)pBuf)[wrote];
>
>   }
>
>   if( !rc || amt>(int)wrote ){
>
>     return SQLITE_FULL;
>
>   }
>
> Is this really a valid occasion to return SQLITE_FULL?

What error code would you suggest as an alternative?
--
D. Richard Hipp   <[hidden email]>



Reply | Threaded
Open this post in threaded view
|

Re: Database Disk Full

D. Richard Hipp
"Drew, Stephen" <[hidden email]> wrote:
>>
> It's just a little bit misleading if you're not familiar with the
> circumstances it's raised in... I've had some confused colleagues
> wondering why their 100kb DB on a disk with 15gb free would be out of
> space :)
>

I'm curious.  What was preventing them from writing to the file
if it was not a lack of disk space?  File permission problems
should have been detected when the file was opened.  What else
would cause a short write?

--
D. Richard Hipp   <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

sqlite-3.3.3 coredumps on SGI IRIX64

Hamid Benhocine
In reply to this post by Drew, Stephen
Hello, I m trying to upgrade from sqlite-3.2.7 on SGI IRIX64 to sqlite-3.3.3
The applications using sqlite-3.2.7 (compiled with mode 64 or 32 bits) work
fine. But the upgrade to sqlite-3.3.3 coredump on 64 bits when creating
tables
with the UNIQUE, PRIMARY constraints. I did not run in this issue with the
earlier versions (sqlite-3.2.5--> sqlite-3.2.7).
May be can any one help.
thanks
Hamid

irix64% cat test.sql
CREATE TABLE t ( a INTEGER  NOT NULL, b INTEGER NOT NULL, rval  REAL ,
UNIQUE(a,b));

irix64% sqlite64 test.db
SQLite version 3.2.7
Enter ".help" for instructions
sqlite> .read test.sql
sqlite> .schema
CREATE TABLE t ( a INTEGER  NOT NULL, b INTEGER NOT NULL, rval  REAL ,
UNIQUE(a,b));
sqlite> .quit
irix64% rm test.db

irix64% ./sqlite test.db
SQLite version 3.3.3
Enter ".help" for instructions
sqlite> .read test.sql
Bus error(coredump)
irix64% rm test.db
irix64% rm core
irix64% dbx ./sqlite                                            
dbx version 7.3.7 (96015_Nov16 MR) Nov 16 2004 07:34:16
Executable /home/afsd/hmd/tmp/sqlite-3.3.3/./sqlite
(dbx) r test.db
Process 345139655 (sqlite) started
SQLite version 3.3.3
Enter ".help" for instructions
sqlite> .read test.sql
Process 345139655 (sqlite) stopped on signal SIGBUS: Bus error (default)
at [sqlite3CreateIndex:2421 +0x18,0x1004bae8]
2421  pIndex->azColl[i] = zColl;
(dbx) where
 >  0 sqlite3CreateIndex(pParse = 0xfffffff8040, pName1 = (nil), pName2
= (nil), pTblName = (nil), pList = 0x100896d0, onError = 99, pStart =
(nil), pEnd = (nil), sortOrder = 0, ifNotExist = 0)
["/home/afsd/hmd/tmp/sqlite-3.3.3/build.c":2421, 0x1004bae8]
   1 yy_reduce(yypParser = 0x10090c38, yyruleno = 87)
["/home/afsd/hmd/tmp/sqlite-3.3.3/parse.y":315, 0x100390f4]
   2 sqlite3Parser(yyp = 0x10090c38, yymajor = 20, yyminor = struct Token {
    z = 0x1008a96a = ");"
    dyn = 0
    n = 1
}, pParse = 0xfffffff8040)
["/home/afsd/hmd/tmp/sqlite-3.3.3/parse.c":3218, 0x1003b820]
   3 sqlite3RunParser(pParse = 0xfffffff8040, zSql = 0x1008a918 =
"CREATE TABLE t ( a INTEGER  NOT NULL, b INTEGER NOT NULL, rval  REAL ,
UNIQUE(a,b));", pzErrMsg = 0xfffffff8020)
["/home/afsd/hmd/tmp/sqlite-3.3.3/tokenize.c":391, 0x10037df0]
   4 sqlite3_prepare(db = 0x1008a978, zSql = 0x1008a918 = "CREATE TABLE
t ( a INTEGER  NOT NULL, b INTEGER NOT NULL, rval  REAL ,
UNIQUE(a,b));", nBytes = -1, ppStmt = 0xfffffff8198, pzTail =
0xfffffff81b8) ["/home/afsd/hmd/tmp/sqlite-3.3.3/prepare.c":539, 0x100364e4]
   5 sqlite3_exec(db = 0x1008a978, zSql = 0x1008a918 = "CREATE TABLE t (
a INTEGER  NOT NULL, b INTEGER NOT NULL, rval  REAL , UNIQUE(a,b));",
xCallback = 0x1000b2a0, pArg = 0xfffffffa1f8, pzErrMsg = 0xfffffff8250)
["/home/afsd/hmd/tmp/sqlite-3.3.3/legacy.c":56, 0x100759f8]
   6 process_input(p = 0xfffffffa1f8, in = 0xdb31088)
["/home/afsd/hmd/tmp/sqlite-3.3.3/shell.c":1487, 0x10010130]
   7 do_meta_command(zLine = 0x10089848 = ".read", p = 0xfffffffa1f8)
["/home/afsd/hmd/tmp/sqlite-3.3.3/shell.c":1219, 0x1000ed28]
   8 process_input(p = 0xfffffffa1f8, in = (nil))
["/home/afsd/hmd/tmp/sqlite-3.3.3/shell.c":1456, 0x1000fe48]


The sqlite-3.2.7 and sqlite-3.3.3 are compiled
this way

rm tclsqlite.c libsqlite.a sqlite 2> /dev/null
for i in *.c
   do
      echo $i
      cc -64 -g  -c $i
done
rm shell.o
ar scru libsqlite.a *.o
cc -64 -g  -o sqlite shell.c libsqlite.a

Reply | Threaded
Open this post in threaded view
|

Re: sqlite-3.3.3 coredumps on SGI IRIX64

D. Richard Hipp
Hamid Benhocine <[hidden email]> wrote:
> Hello, I m trying to upgrade from sqlite-3.2.7 on SGI IRIX64 to sqlite-3.3.3
> The applications using sqlite-3.2.7 (compiled with mode 64 or 32 bits) work
> fine. But the upgrade to sqlite-3.3.3 coredump on 64 bits when creating
> tables
> with the UNIQUE, PRIMARY constraints. I did not run in this issue with the
> earlier versions (sqlite-3.2.5--> sqlite-3.2.7).

PRIMARY KEY implies UNIQUE.  Including them both is redundant.
Nevertheless, it should give you a segfault.

Please send the SQL that fails.

--
D. Richard Hipp   <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

re: Database Disk Full

Dave Dyer
In reply to this post by D. Richard Hipp
At 09:00 AM 2/10/2006, [hidden email] wrote:

>"Drew, Stephen" <[hidden email]> wrote:
>> Hello,
>>  
>> In sqlite3OsWrite function (in os_win.c)  the following code exists:
>>  
>>   while( amt>0 && (rc = WriteFile(id->h, pBuf, amt, &wrote, 0))!=0 &&
>> wrote>0 ){
>>
>>     amt -= wrote;
>>
>>     pBuf = &((char*)pBuf)[wrote];
>>
>>   }
>>
>>   if( !rc || amt>(int)wrote ){
>>
>>     return SQLITE_FULL;
>>
>>   }
>>
>> Is this really a valid occasion to return SQLITE_FULL?
>
>What error code would you suggest as an alternative?

IMO the error code is fine, but there should be an auxiliary API
that provides all available information (file name, windows error code,
windows error description, current file size, ...), if only to facilitate
the "duh" reaction when the user realizes what's really wrong.

Reply | Threaded
Open this post in threaded view
|

Re: sqlite-3.3.3 coredumps on SGI IRIX64

D. Richard Hipp
In reply to this post by Hamid Benhocine
Hamid Benhocine <[hidden email]> wrote:
> Hello, I m trying to upgrade from sqlite-3.2.7 on SGI IRIX64 to sqlite-3.3.3
> The applications using sqlite-3.2.7 (compiled with mode 64 or 32 bits) work
> fine. But the upgrade to sqlite-3.3.3 coredump on 64 bits when creating
> tables
> with the UNIQUE, PRIMARY constraints.

People with 64-bit alignment sensitive machines:  Please tell
me if check-in [3079] solves your problems.

http://www.sqlite.org/cvstrac/chngview?cn=3079

--
D. Richard Hipp   <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

RE: Database Disk Full

Drew, Stephen
In reply to this post by Drew, Stephen
I suspect, although am not 100%, that a third-party database tool was
using the database file. As you say, I would have expected either that
tool or the actual program to have failed to open the file....

However, we could be a lot more sure if we could see the Win32 error. In
the short-term I am going to add a modification to log this info
whenever WriteFile() fails in the code mentioned, and will let you know
if it is anything that looks suspicious.

Out of interest, the file is on a local NT filesystem drive.

Thanks,
Steve

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: 10 February 2006 17:28
To: [hidden email]
Subject: Re: [sqlite] Database Disk Full

"Drew, Stephen" <[hidden email]> wrote:
>>
> It's just a little bit misleading if you're not familiar with the
> circumstances it's raised in... I've had some confused colleagues
> wondering why their 100kb DB on a disk with 15gb free would be out of
> space :)
>

I'm curious.  What was preventing them from writing to the file if it
was not a lack of disk space?  File permission problems should have been
detected when the file was opened.  What else would cause a short write?

--
D. Richard Hipp   <[hidden email]>



Reply | Threaded
Open this post in threaded view
|

Re: sqlite-3.3.3 coredumps on SGI IRIX64

Hamid Benhocine
In reply to this post by D. Richard Hipp
[hidden email] wrote:

>Hamid Benhocine <[hidden email]> wrote:
>  
>
>>Hello, I m trying to upgrade from sqlite-3.2.7 on SGI IRIX64 to sqlite-3.3.3
>>The applications using sqlite-3.2.7 (compiled with mode 64 or 32 bits) work
>>fine. But the upgrade to sqlite-3.3.3 coredump on 64 bits when creating
>>tables
>>with the UNIQUE, PRIMARY constraints.
>>    
>>
>
>People with 64-bit alignment sensitive machines:  Please tell
>me if check-in [3079] solves your problems.
>
>http://www.sqlite.org/cvstrac/chngview?cn=3079
>
>--
>D. Richard Hipp   <[hidden email]>
>
>
>  
>
replacing build.c table.c and sqliteInt.h ins sqlite-3.3.3 with
those of ticket 3079

all the Problems are fixed

I was able to run the regression tests and
the results are

5 errors out of 23846 tests
Failures on these tests: printf-8.2 sync-1.1 sync-1.2 sync-1.3
types3-1.3 (they are related to tcl!!)

GREAT JOB. thanks a lot.

Hamid

Reply | Threaded
Open this post in threaded view
|

Re: Database Disk Full

John Stanton-3
In reply to this post by Drew, Stephen
Since the file access has already worked by this stage the "plethora" is
far smaller than you may have appreciated.  It is a reasonable
assumption to make that the only thing which can have changed since the
last write is the disk becoming full.  A disk cable falling off, head
crash or mechanical disk failure is not only unlikely but would crash
the entire machine and make error detection and recovery unlikely so
testing for it is futile.
JS

Drew, Stephen wrote:

> Hello,
>  
> In sqlite3OsWrite function (in os_win.c)  the following code exists:
>  
>   while( amt>0 && (rc = WriteFile(id->h, pBuf, amt, &wrote, 0))!=0 &&
> wrote>0 ){
>
>     amt -= wrote;
>
>     pBuf = &((char*)pBuf)[wrote];
>
>   }
>
>   if( !rc || amt>(int)wrote ){
>
>     return SQLITE_FULL;
>
>   }
>
> Is this really a valid occasion to return SQLITE_FULL?   Surely
> WriteFile Win32 API call can fail to write a full for a plethora of
> reasons, or am I missing something?
>
> Many thanks in advance
>
> Regards,
>
> Steve
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Database Disk Full

Dave Dyer

>It is a reasonable assumption to make that the only thing which can have changed since the last write is the disk becoming full.  A disk cable falling off, head crash or mechanical disk failure is not only unlikely but would crash the entire machine and make error detection and recovery unlikely so testing for it is futile.

It is reasonable for a program like sqlite to operate
on the assumption that other hardware and software perform as
intended, and not attempt heroic error recovery.

On the other hand, sqlite operates in the real world, and wierd
shit happens out there.  When something goes wrong, every bit of
information that is available should BE available to those trying
to clean up the mess.

There is a huge difference, coming in in the morning after an expected
overnight run, finding it failed, and having the message

database full

verses having the message

09-feb-2006 03:13:12 database write failed, windows error code 14
 for f:\temp\vacuumtemp.txt, current file size = 10200K


Reply | Threaded
Open this post in threaded view
|

Re: Re: Database Disk Full

John Stanton-3
The first message informs all users of the problem.  The one you propose
might satisfy a technonerd, but confuse the more casual user.  There is
however a case for writing such a detailed message to syslog or similar
system log.

Dave Dyer wrote:

>>It is a reasonable assumption to make that the only thing which can have changed since the last write is the disk becoming full.  A disk cable falling off, head crash or mechanical disk failure is not only unlikely but would crash the entire machine and make error detection and recovery unlikely so testing for it is futile.
>
>
> It is reasonable for a program like sqlite to operate
> on the assumption that other hardware and software perform as
> intended, and not attempt heroic error recovery.
>
> On the other hand, sqlite operates in the real world, and wierd
> shit happens out there.  When something goes wrong, every bit of
> information that is available should BE available to those trying
> to clean up the mess.
>
> There is a huge difference, coming in in the morning after an expected
> overnight run, finding it failed, and having the message
>
> database full
>
> verses having the message
>
> 09-feb-2006 03:13:12 database write failed, windows error code 14
>  for f:\temp\vacuumtemp.txt, current file size = 10200K
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Re: Database Disk Full

Drew, Stephen
In reply to this post by Drew, Stephen
John,

Thanks for the reply.

I disagree - my error message informs my users (who are technonerds)
that the disk or db file is full, when neither of these is the case.

Surely you can see that even a different constant error message in this
context would be preferable?  SQLITE_WRITE_FAILED or something?

As I say, I'm just altering the standard error text at the moment,
because it is misleading.

Steve

-----Original Message-----
From: John Stanton [mailto:[hidden email]]
Sent: 11 February 2006 09:58
To: [hidden email]
Subject: Re: [sqlite] Re: Database Disk Full

The first message informs all users of the problem.  The one you propose
might satisfy a technonerd, but confuse the more casual user.  There is
however a case for writing such a detailed message to syslog or similar
system log.

Dave Dyer wrote:
>>It is a reasonable assumption to make that the only thing which can
have changed since the last write is the disk becoming full.  A disk
cable falling off, head crash or mechanical disk failure is not only
unlikely but would crash the entire machine and make error detection and
recovery unlikely so testing for it is futile.

>
>
> It is reasonable for a program like sqlite to operate on the
> assumption that other hardware and software perform as intended, and
> not attempt heroic error recovery.
>
> On the other hand, sqlite operates in the real world, and wierd shit
> happens out there.  When something goes wrong, every bit of
> information that is available should BE available to those trying to
> clean up the mess.
>
> There is a huge difference, coming in in the morning after an expected

> overnight run, finding it failed, and having the message
>
> database full
>
> verses having the message
>
> 09-feb-2006 03:13:12 database write failed, windows error code 14  for

> f:\temp\vacuumtemp.txt, current file size = 10200K
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Re: Database Disk Full

John Stanton-3
Sigh...  what is wrong with a message "disk full" when the disk space is
exhausted?  Why is simple and to the point a problem?

Drew, Stephen wrote:

> John,
>
> Thanks for the reply.
>
> I disagree - my error message informs my users (who are technonerds)
> that the disk or db file is full, when neither of these is the case.
>
> Surely you can see that even a different constant error message in this
> context would be preferable?  SQLITE_WRITE_FAILED or something?
>
> As I say, I'm just altering the standard error text at the moment,
> because it is misleading.
>
> Steve
>
> -----Original Message-----
> From: John Stanton [mailto:[hidden email]]
> Sent: 11 February 2006 09:58
> To: [hidden email]
> Subject: Re: [sqlite] Re: Database Disk Full
>
> The first message informs all users of the problem.  The one you propose
> might satisfy a technonerd, but confuse the more casual user.  There is
> however a case for writing such a detailed message to syslog or similar
> system log.
>
> Dave Dyer wrote:
>
>>>It is a reasonable assumption to make that the only thing which can
>
> have changed since the last write is the disk becoming full.  A disk
> cable falling off, head crash or mechanical disk failure is not only
> unlikely but would crash the entire machine and make error detection and
> recovery unlikely so testing for it is futile.
>
>>
>>It is reasonable for a program like sqlite to operate on the
>>assumption that other hardware and software perform as intended, and
>>not attempt heroic error recovery.
>>
>>On the other hand, sqlite operates in the real world, and wierd shit
>>happens out there.  When something goes wrong, every bit of
>>information that is available should BE available to those trying to
>>clean up the mess.
>>
>>There is a huge difference, coming in in the morning after an expected
>
>
>>overnight run, finding it failed, and having the message
>>
>>database full
>>
>>verses having the message
>>
>>09-feb-2006 03:13:12 database write failed, windows error code 14  for
>
>
>>f:\temp\vacuumtemp.txt, current file size = 10200K
>>
>>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Re: Database Disk Full

Michael Knigge

> Sigh...  what is wrong with a message "disk full" when the disk space is
> exhausted?  Why is simple and to the point a problem?

The point is, that this error is returned everytime a write to the disk
failed - even if (for example) the write failed because of a network
error (NFS-Server is restarted for example).


I remember that I've got a "disk full" message from MS-Word last year
when I tried to print to a PDF-Printer (free space on my disk: 14 GB).



Bye,
   Michael



>
> Drew, Stephen wrote:
>
>> John,
>>
>> Thanks for the reply.
>>
>> I disagree - my error message informs my users (who are technonerds)
>> that the disk or db file is full, when neither of these is the case.
>>
>> Surely you can see that even a different constant error message in this
>> context would be preferable?  SQLITE_WRITE_FAILED or something?
>>
>> As I say, I'm just altering the standard error text at the moment,
>> because it is misleading.
>>
>> Steve
>>
>> -----Original Message-----
>> From: John Stanton [mailto:[hidden email]] Sent: 11 February 2006
>> 09:58
>> To: [hidden email]
>> Subject: Re: [sqlite] Re: Database Disk Full
>>
>> The first message informs all users of the problem.  The one you propose
>> might satisfy a technonerd, but confuse the more casual user.  There is
>> however a case for writing such a detailed message to syslog or similar
>> system log.
>>
>> Dave Dyer wrote:
>>
>>>> It is a reasonable assumption to make that the only thing which can
>>
>>
>> have changed since the last write is the disk becoming full.  A disk
>> cable falling off, head crash or mechanical disk failure is not only
>> unlikely but would crash the entire machine and make error detection and
>> recovery unlikely so testing for it is futile.
>>
>>>
>>> It is reasonable for a program like sqlite to operate on the
>>> assumption that other hardware and software perform as intended, and
>>> not attempt heroic error recovery.
>>>
>>> On the other hand, sqlite operates in the real world, and wierd shit
>>> happens out there.  When something goes wrong, every bit of
>>> information that is available should BE available to those trying to
>>> clean up the mess.
>>>
>>> There is a huge difference, coming in in the morning after an expected
>>
>>
>>
>>> overnight run, finding it failed, and having the message
>>>
>>> database full
>>>
>>> verses having the message
>>>
>>> 09-feb-2006 03:13:12 database write failed, windows error code 14  for
>>
>>
>>
>>> f:\temp\vacuumtemp.txt, current file size = 10200K
>>>
>>>
>>
>>
>>
>>
>
>


--
Mit freundlichen Grüßen

Michael Knigge

S.E.T. Software GmbH
Lister Str. 15
30163 Hannover

Tel.:  +49 511 / 3 97 80 -23
Fax:   +49 511 / 3 97 80 -66
eMail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Re: Database Disk Full

Drew, Stephen
In reply to this post by Drew, Stephen
Exactly, as per my original mail, there was no shortage of disk space on the drive in question, on the drive containing the temporary files, and the database file was 100kb.

So SQLITE_FULL was misleading in this case.

I will post further information about the exact cause when I have tracked it down.

Regards,
Steve

-----Original Message-----
From: Michael Knigge [mailto:[hidden email]]
Sent: 13 February 2006 13:34
To: [hidden email]
Subject: Re: [sqlite] Re: Database Disk Full


> Sigh...  what is wrong with a message "disk full" when the disk space
> is exhausted?  Why is simple and to the point a problem?

The point is, that this error is returned everytime a write to the disk failed - even if (for example) the write failed because of a network error (NFS-Server is restarted for example).


I remember that I've got a "disk full" message from MS-Word last year when I tried to print to a PDF-Printer (free space on my disk: 14 GB).



Bye,
   Michael



>
> Drew, Stephen wrote:
>
>> John,
>>
>> Thanks for the reply.
>>
>> I disagree - my error message informs my users (who are technonerds)
>> that the disk or db file is full, when neither of these is the case.
>>
>> Surely you can see that even a different constant error message in this
>> context would be preferable?  SQLITE_WRITE_FAILED or something?
>>
>> As I say, I'm just altering the standard error text at the moment,
>> because it is misleading.
>>
>> Steve
>>
>> -----Original Message-----
>> From: John Stanton [mailto:[hidden email]] Sent: 11 February 2006
>> 09:58
>> To: [hidden email]
>> Subject: Re: [sqlite] Re: Database Disk Full
>>
>> The first message informs all users of the problem.  The one you propose
>> might satisfy a technonerd, but confuse the more casual user.  There is
>> however a case for writing such a detailed message to syslog or similar
>> system log.
>>
>> Dave Dyer wrote:
>>
>>>> It is a reasonable assumption to make that the only thing which can
>>
>>
>> have changed since the last write is the disk becoming full.  A disk
>> cable falling off, head crash or mechanical disk failure is not only
>> unlikely but would crash the entire machine and make error detection and
>> recovery unlikely so testing for it is futile.
>>
>>>
>>> It is reasonable for a program like sqlite to operate on the
>>> assumption that other hardware and software perform as intended, and
>>> not attempt heroic error recovery.
>>>
>>> On the other hand, sqlite operates in the real world, and wierd shit
>>> happens out there.  When something goes wrong, every bit of
>>> information that is available should BE available to those trying to
>>> clean up the mess.
>>>
>>> There is a huge difference, coming in in the morning after an expected
>>
>>
>>
>>> overnight run, finding it failed, and having the message
>>>
>>> database full
>>>
>>> verses having the message
>>>
>>> 09-feb-2006 03:13:12 database write failed, windows error code 14  for
>>
>>
>>
>>> f:\temp\vacuumtemp.txt, current file size = 10200K
>>>
>>>
>>
>>
>>
>>
>
>


--
Mit freundlichen Grüßen

Michael Knigge

S.E.T. Software GmbH
Lister Str. 15
30163 Hannover

Tel.:  +49 511 / 3 97 80 -23
Fax:   +49 511 / 3 97 80 -66
eMail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Database Disk Full

Dave Dyer
In reply to this post by John Stanton-3
At 04:47 AM 2/13/2006, John Stanton wrote:
>Sigh...  what is wrong with a message "disk full" when the disk space is exhausted?  Why is simple and to the point a problem?

The "disk full" error is actually "write failed".  Disk full may be
the expected reason for a write to fail, but there are many others,
not all even documented.

Under most circumstances, you'll look at the disk space situation and
decide "oh sure"; but what if your reaction is "huh?" and all the
information  you have is "disk full".

For example, some operating systems support disk quotas, and a write
will fail when you exceed the quota.  In that case, if you're lucky,
the error code might mean "quota exceeded".  If all you got from sqlite
is a generic disk full message, not based on the actual error code,
you're still clueless.

-- I'm not saying sqlite should to try to diagnose every possible failure,
but when the unexpected inevitably happens, sqlite should make as much
information as possible available to the host application.  It's all part
of building reliable and debuggable applications.