On Thu, Jun 11, 2009 at 12:51:17PM -0400, Jérôme Poulin wrote: > > > > On Thu, Jun 11, 2009 at 11:39:50AM -0400, Luis Useche wrote: > > With the current GC implementation, I am unable to do my experiment. I set > > "protection_period 0" but still have the problem. Besides, this is > > probably not the right solution either since the GC can do unnecessary work > > that can underestimate the potential of nilfs. I need the first option (1) > > from the first paragraph above. > > > > For this situation, would it be possible instead, to have to GC collect all > the space that can be freed, have the filesystem informed of what blocks can > be freed anytime (like a memory cache which can be flushed anytime), and > have the FS give the free space information for what it calculated as > removable? So with this we could have checkpoint for longuer than the > protection_period and still have the free space available for thing the > filesystem can just overwrite. I really don't know how it is coded as I'm > just a user for now, but that would be even greater.
I am in favor of this solution. Ideally, if the user does not want to protect any data (like in my case), the filesystem should not report space shortage when plenty of space is available to overwrite. Instead, the GC must start working right away to make enough room for the incoming writes. -- Luis Useche <[email protected]> Ph.D. Student Florida International University _______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
