#7324 closed bug (invalid)
file cache does not flush
| Reported by: | stargatefan | Owned by: | axeld |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | System/Kernel | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
File cahce does not flush on big disk writes. Using the sync command does not free the memory. this is especially noticeable moving large files from one parition to the next.
Present for some time no explicit version info.
Change History (5)
comment:1 by , 14 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:2 by , 14 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
When copying a large movie file from drive A to drive B the cache gets loaded and stays loaded until shut down. I appreciate the performance benefits of file cacheing, but does it need to cache a whole dvd in ram ? Not trying to be a Pet Theorizer here but I wonder if this behavior effects the disk write issue I have been observing ? Also I have noticed the cache will clear about 50% of a large media file, then stop. sync will not allow for the unmount of the drive either.
thought it might be worth mentioning. I don't know if its related but I thought it might be worth a mention. would it not make sense to flush the cache after a period of time ?
comment:3 by , 14 years ago
I don't know what your mental model for the file cache is, but it sounds wrong. The data is not "held" in the cache before being written to disk - it is written to disk at the same time, but kept in memory as well in case an app tries to access the data again. There is really no need to "flush" the cache - if a running app needs more memory then some of the cache data will be freed to make room.
This one's still invalid, but the other ticket you opened about the write not completing certainly sounds like a bug and still needs more info (a syslog would probably help).
comment:5 by , 14 years ago
The unmount will definitely have a different reason (like an open file handle left, Tracker sometimes does this). After sync, the file is completely written back.
Also note, that Haiku does not write synchronously to USB drives, ie. it needs to sync before an unmount which means that this might take a while to perform.
That's perfectly normal behaviour. Your memory doesn't benefit from sitting around unused, Haiku always tries to utilize as much memory as possible.
If that's not what you mean, please be more specific. I'm closing this as invalid for now, though.