diff options
| author |  Joey Hess <joeyh@joeyh.name> | 2016-02-26 13:49:26 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2016-02-26 13:49:26 -0400 |
| commit | afc6b48604da577b9c638c73ee2ccaec3e96cb84 (patch) | |
| tree | 3acdf1a63aae9918ca3654eb761048c9b44dae0e | |
| parent | 3958161bd860e2c4f5b40fffdceed1fc6e8ad871 (diff) | |
bug
| -rw-r--r-- | doc/bugs/checksum_loads_whole_file_into_memory.mdwn | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/doc/bugs/checksum_loads_whole_file_into_memory.mdwn b/doc/bugs/checksum_loads_whole_file_into_memory.mdwn new file mode 100644 index 000000000..c00d3a96b --- /dev/null +++ b/doc/bugs/checksum_loads_whole_file_into_memory.mdwn @@ -0,0 +1,13 @@ +Using eg, fsck with the MD5 backend loads whole files into memory. + +May only happen for very large files (40 gb) or in other specific +circumstances, including ghc version used for buildd etc. + +Observed with 6.20160217-g95bbdb8, linux standalone amd64. + +Not observed with 5.20151218-g5008846. + +Commit 7482853ddddc21f2696dcfbc82d737f03032134a may be relevant, +but I don't understand how yet. A small test program using the same +code doesn't exhibit the problem, even when built in the identical build +environment as the 6.20160217-g95bbdb8 that has the problem. |