I used to JFS. JFS used to (maybe still) have the problem of indefinite cache flush that is the write cache will not be flushed until the "flush trigger" is fired. But in case of JFS, if I copy a lot of reasonable large files, it seems that only the last one will have part of the content remain in the cache. But with XFS, it "seems" to me that the file system dedicates some cache space to the meta data, even new data is loading into the cache, the meta data part seems not to be flushed. |
At least, in your case, xfs_repair can detect errors, but in my case, it does not find anything.
On Sat, Dec 8, 2012 at 8:53 PM, Matthias Schniedermeyer <ms@xxxxxxx>
On 08.12.2012 20:40, Michael Monnerie wrote:Now that you say it, this is what happend one of the other times,
> Am Samstag, 8. Dezember 2012, 20:29:27 schrieb Matthias Schniedermeyer:
> > I have the same problem, several times.
> I'd like to chime in here, with a similar issue: I have Linux on my
> desktop, xfs is the home partition, 16G RAM. One day my system froze, no
> chance to do a buffer flush via SYS-S/U/B, I had to press the reset
> button (no power off, just reset). Upon restart, *lots* of files were
> gone, destroyed, etc, and my KDE desktop wouldn't work anymore. Luckily
> I have backups, and could restore - but this just shouldn't happen, and
> it was *much* better with older kernels. What is the problem that
> metadata isn't written to disk occasionally? I was on 3.6.6 when that
> happened, now on 3.6.8, so very recent.
luckily i had done a backup just before i rebooted, so after
xfs_repair'ing the partition (the only time i had to repair something
for as long as i'm using XFS) i had to restore my home-directory from
backup to get my desktop in a usable state again.