diff options
| author | Valdis Klētnieks <valdis.kletnieks@vt.edu> | 2019-10-02 15:01:35 -0400 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2019-10-04 10:17:57 +0200 |
| commit | d98bb9c2fec01254d2e04e1eed51dde9ae611314 (patch) | |
| tree | 9d47083f415af551051847ecf2fe2081d3591eb4 /drivers/staging/exfat/TODO | |
| parent | 8789f13ddc77723e9451548b984382605340899c (diff) | |
| download | linux-d98bb9c2fec01254d2e04e1eed51dde9ae611314.tar.gz linux-d98bb9c2fec01254d2e04e1eed51dde9ae611314.tar.bz2 linux-d98bb9c2fec01254d2e04e1eed51dde9ae611314.zip | |
staging: exfat: explain the fs_sync() issue in TODO
We've seen several incorrect patches for fs_sync() calls in the exfat driver.
Add code to the TODO that explains this isn't just a delete code and refactor,
but that actual analysis of when the filesystem should be flushed to disk
needs to be done.
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Link: https://lore.kernel.org/r/9837.1570042895@turing-police
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/staging/exfat/TODO')
| -rw-r--r-- | drivers/staging/exfat/TODO | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/drivers/staging/exfat/TODO b/drivers/staging/exfat/TODO index a3eb282f9efc..b60e50b9cf4e 100644 --- a/drivers/staging/exfat/TODO +++ b/drivers/staging/exfat/TODO @@ -3,6 +3,15 @@ same for ffsWriteFile. exfat_core.c - fs_sync(sb,0) all over the place looks fishy as hell. There's only one place that calls it with a non-zero argument. +Randomly removing fs_sync() calls is *not* the right answer, especially +if the removal then leaves a call to fs_set_vol_flags(VOL_CLEAN), as that +says the file system is clean and synced when we *know* it isn't. +The proper fix here is to go through and actually analyze how DELAYED_SYNC +should work, and any time we're setting VOL_CLEAN, ensure the file system +has in fact been synced to disk. In other words, changing the 'false' to +'true' is probably more correct. Also, it's likely that the one current +place where it actually does an bdev_sync isn't sufficient in the DELAYED_SYNC +case. ffsTruncateFile - if (old_size <= new_size) { That doesn't look right. How did it ever work? Are they relying on lazy |