Opened 2 years ago
Closed 4 months ago
#18126 closed bug (no change required)
RAMFS: does not reserve memory for files
Reported by: | waddlesplash | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | File Systems/RAMFS | Version: | R1/beta4 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
As in title. This can get us in to trouble, in that files which have been resized do not actually have the necessary capacity and can have errors occur at write time (or page faults in applications that have mmap'ed them) in low memory situations.
Change History (3)
comment:1 by , 13 months ago
comment:2 by , 13 months ago
Well, another thing we may want to implement would be a global quota for RAMFS, so that one can restrict it to only use some maximum size or percent of system RAM, or not allocate more RAM if only so much is available. At present there's no mechanism for that either.
comment:3 by , 4 months ago
Resolution: | → no change required |
---|---|
Status: | new → closed |
Turns out the VMCache already does this for us, so we don't need to do anything particular in RAMFS for it. A global quota or limit might be nice, but if we do decide to add that, it deserves another ticket. Given that RAMFS is used for generic POSIX shared memory, a quota might not make much sense, though.
Sparse files are a thing on filesystems (similar to overcommitting in RAM) and may lead to the same problems on a traditional block device backed filesystem.
Is there anything special about ramfs here? Write and read on block devices can fail, that can be handled by the corresponding APIs returning an error. And if you use mmap, likewise, if you plan to have the file added to your address space as you access it, you should be prepared to handle errors (by catching signals when accessing it, I assume). But that is also not different from any other filesystem.