On Tue, Jun 23, 2009 at 07:47:20AM -0400, T-Machine wrote: > Hi; Using NILFS2 - nilfs-utils-2.0.12 / 2.0.14 - w. kernel ..6.29.5 & > ..6.30 (Slackware & SlamD & BW64)... > ... tried both, as part of the main tree, as well as modules. > 1) Problem - example: bonnie++ "Drastic I/O error (write(2)): No space > left on device"; (8G space 2G RAM) > Same in "direct" writes - no bonnie++ etc. > The nilfs partition simply runs out of space at ~10%.
One thing I've been wondering about is this notion that checkpoints
younger than some amount of time t are protected, no matter what. I
don't know if there's some hard design decision which forces that, but
it seems to me that often it's desirable to have checkpoints "if
possible", but not at the cost of writes failing. Of course there are
clearly also cases where the current behavior of guaranteed protection
for young check points is desirable.
Well, I'm not at all familiar with nilfs2 internals, so I hope I'm not
talking too much about issues I don't understand and stepping onto
other people's toes :-), but it seems to me it might at least be
useful to have two separate configurable periods instead of the
current protection_period, so I could configure something like
soft_protection_period=3600
hard_protection_period=600
where the fs would behave something like
- freely garbage collect cps older than soft_protection_period (just
as AFAIK is now done to cps older than protection_period),
- never garbage collect cps younger than hard_correction period (just
as is now done to cps younger than protection period), and
- make a best effort to not garbage collect cps younger than
soft_protection_period but older than hard_protection period, unless
for a reason like being low on disk space
(Generally in my current use cases I haven't been very interested in
the checkpointing features of nilfs2, so I would probably have wanted
to set something like soft_protection_period=3600 and
hard_protection_period=0 if possible.)
Sami
signature.asc
Description: Digital signature
_______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
