Thanks all for the useful inputs. One more question I have is can the 1034 error code ever mean that disk is full or nvram is full and hence it cannot fsync ?depending on different nvram drivers, may be some nvram drivers don't implement the interface well and hence if disk is fullm fsync fails . Can that happen ?
-----Original Message----- From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Scott Doctor Sent: Tuesday, June 23, 2015 3:33 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] sqlite error code 1034 An fsync error with nvram may be caused by a timeout during the write cycle. write cycles in nvram can be many times longer than a read cycle in this type of memory. Trying to write a large buffer of data may take multiple seconds especially if adresses are non-linear depending on size and technology of the nvram. Try more frequent fsyncs, or extending system timeouts as a test. Errors happen for a reason and should not ever be ignored without knowing the cause. Another problem with nvram is limited number of write cycles. if a particular memory location is constantly in read/write cycles it is possible that the memory is near the end of its life and needs to be replaced. ------------ Scott Doctor scott at scottdoctor.com On 6/23/2015 1:09 AM, Simon Slavin wrote: > On 23 Jun 2015, at 6:01am, Mayank Kumar (mayankum) <mayankum at cisco.com> > wrote: > >> Do you think if sqlite3_step or sqlite3_open fail with this error, we should >> treat this as transaction committed and ignore the fsync error and it will >> be retried with the next commit or read and eventually will sync unless I >> see this error continuously in which case we can treat this as catastrophic. >> >> Also I wanted to know if fsync requires space on the filesystem since in our >> case nvram has little space(200mb), do you think fsync could fail because of >> that as well? > You can't ignore fsync() since it indicates that future changes to the file > may not be valid, with no errors reporting the problems (because an error has > already been reported). So yes your program should crash. > > But I've never seen fsync() in real life except when it indicated a hardware > problem of some kind -- either a badly connected cable or a bug in the mass > storage driver. Software problems which might cause fsync() to fail are > beyond my competence. Sorry. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
