© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
@Theo:
Something is bothering me... I like laptop mode's ability to buffer writes to memory while keeping the hard drive spun down. I have 4 GB of RAM and wrote a script to cache a ton of system and user files to memory so I can start programs, then edit and save files with the disk remaining off most of the time.
Are you saying there's no safe way to save over a file without spinning up the disk immediately? And that every file editor should call fsync when saving? I don't want a spin-up to occur every time I save a file. There's already a limit set for how long my data can be held in memory before being written, so I'm not worried about losing ten minutes of work in the rare instance of a particularly bad crash where I can't sync before rebooting. But I am worried about the possibility of losing the entire file.
So I want the update of the file to be safe, but I don't want to throw away the benefits of laptop mode to obtain that safety. Ext3 has never failed me in this regard and given me a zero-byte file, even though I've allowed it to hold changes in memory for long intervals.
I see one of your patches forces the file data to be flushed out alongside a rename when a file is replaced. Would the opposite be feasible? That is, instead of flushing the file data earlier, hold off on committing the rename until everything the file contained at the time of the rename is flushed to disk. Hopefully doing it that way could retain the performance of delayed allocation. Programs already use the write-and-rename pattern to atomically create or replace files, and it'd be nice if this atomicity was preserved even in the event of a crash.