Marcel Hilzinger wrote: > Am Dienstag, 22. November 2005 11:38 schrieb Sander: > >>Marcel Hilzinger wrote (ao): >> >>>Did you ever think about, that this is not a reiser4 problem, but a >>>kernel bug or a problem related to hal? >>> >>>Suse 10 has big problems with external USB drives using sync as mount >>>option. They used sync already in 9.3 but with 2.6.11 there were no >>>such problems. There has been some changes in kernel 2.6.13 and 2.6.14 >>>concering the sync behavior, perhaps it can help investigating there >>>first, bevor fixing reiser4 for nothing... >> >>Running Debian here, and all the reports have been on Reiser4 >>filesystems. Also, the same system has no such problems with other >>filesystems. > > It's not about Debian or Suse. It's about kernel 2.6.13 or 2.6.14. At least > it > seems, that the problem does not appear on older kernels (right?)
Wrong. You are talking about the fsync issue, right? As far as I know, while there has been progress lately, fsync has always been slow on Reiser4, because until recently, it was basically a call to sync, and reiser4 syncs can be huge due to lazy writes -- stuff only ever hits disk when there's nowhere else to put it in RAM. Actual calls to sync are rare enough (shutdown/reboot) that lazy writes are a good thing, but fsync apparently needs to be faster. I disabled fsync before the FS was even stable, because I was sick of waiting 30 seconds or so for vim to save and quit. It may help to have fsync only sync the file in question (as it always has, except on Reiser4). This has been done with lazy writes, in XFS, so I see no reason it can't be done here -- there might have even been a patch recently. Personally, I'd like to see it stay as slow as it is for awhile, so we can find the people doing stupid things (evolution) and flame them into crispy obediance. fsync means flush to disk. This is something you're supposed to do with a file when the file is so important you want to guarentee you'll have the most recent, uncorrupted version after a crash. If evolution is calling fsync while resizing, this is an evolution bug, made more obvious by reiser4 -- if a computer crashes, does the user really care if their Evolution columns are still lined up _exactly_ the way they were (maybe mid-click'n'drag) when the crash occurred? If there is a user who cares that much about column widths, can we flame them to crispiness also?
