Opened 16 years ago
Closed 16 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: | ||
| Platform: | x86 |
Description (last modified by )
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 by , 16 years ago
comment:2 by , 16 years ago
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 by , 16 years ago
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 by , 16 years ago
| Description: | modified (diff) |
|---|---|
| Summary: | file system (BFS) inconsistent after crash (KDL) → files not written to disk (BFS) after crash (KDL) |
comment:5 by , 16 years ago
Is there a way to disable the fs write cache?
And how can the cache be force flushed?
comment:6 by , 16 years ago
| Milestone: | R1 → R1/alpha1 |
|---|---|
| Priority: | normal → blocker |
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 by , 16 years ago
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 by , 16 years ago
| Component: | File Systems/BFS → System/Kernel |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
I think I have seen the same issue on multiple machines.