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 > >
