Opened 10 years ago

Closed 10 years ago

#2781 closed bug (fixed)

files not written to disk (BFS) after crash (KDL)

Reported by: rossi Owned by: axeld
Priority: blocker Milestone: R1/alpha1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description (last modified by jackburton)

After a crash (KDL), files copied to the drive in that session are lost after the reboot following the crash.

However apparently this doesn't affect all files, I have the slight (not proven) feeling, that certain files, which have been touched after the copy operation actually survive the crash.

All this happens on hrev27764, gcc2 build with gcc4 libs installed.

Btw, should I reinitialize the file system to be on the safe side that there are no other hidden not visible issues with the file system?

Change History (8)

comment:1 Changed 10 years ago by jackburton

I think I have seen the same issue on multiple machines.

comment:2 Changed 10 years ago by mmlr

This is not a filesystem inconsistency however. If the filesystem was inconsistent it would for example have corrupted nodes, files with inconsistent block mappings or attributes, indexes and the like. BFS does journaling to avoid exactly that. But this journaling doesn't include data journaling. If you have files that weren't written back yet at all, they will be lost obviously as they only ever existed in your memory. If you have files that were in the process of being written back, they might be missing as well, because the journaling might have removed an incompletely written node, exactly do avoid an inconsistent state. If the metadata was written back, the file might be present, but still the data it contains might be complete junk if it has not yet been written back. Still, the filesystem itself should consistent, from a meta data point of view, in all of these cases. You can force writing back data by using the sync command to avoid such situations. If you do that and still loose data that should have been written before the call, that'd be a bug. But if you loose data that isn't guaranteed to be written back (either by an explicit sync or by the implicit sync on unmount/shutdown) that isn't necessarily a bug.

comment:3 Changed 10 years ago by jackburton

Right. But after a couple of minutes the files should be written back to disk anyway. I guess this is a regression (Luposian bug, again? AAAAAAAAAAAAAAARGH!!!), since this wasn't happening some time ago.

comment:4 Changed 10 years ago by jackburton

Description: modified (diff)
Summary: file system (BFS) inconsistent after crash (KDL)files not written to disk (BFS) after crash (KDL)

comment:5 Changed 10 years ago by rossi

Is there a way to disable the fs write cache?

And how can the cache be force flushed?

comment:6 Changed 10 years ago by mmlr

Milestone: R1R1/alpha1
Priority: normalblocker

As written above already, you can use sync to force-flush changes. There is no way of disabling the file cache I know of. But if it worked for you some time ago and you really need it to work, then you could always revert to a revision that doesn't have this problem.

comment:7 Changed 10 years ago by rossi

Now, if I would just remeber the latest revision without problems ;-( I should start to do some book keeping about revision stability ...

Does anybody happen to know, which was the latest revision without this issue?

It would be nice, if these tags "r1_pre_alpha-somewhat_stable " would be more regularly maintained ... for those who don't read every commit comment.

comment:8 Changed 10 years ago by axeld

Component: File Systems/BFSSystem/Kernel
Resolution: fixed
Status: newclosed

Fixed in hrev27831, the regression happened in hrev27074.

Note: See TracTickets for help on using tickets.