"Drastic I/O error (write(2)): No space left on device"

"Drastic I/O error (write(2)): No space left on device"

[T-Machine]

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%.
2) nilfs_cleanerd does not apper to start with "mount". (Why... seems to 
be somewhat elusive. Can't  replicate consistently.
Now, there was a post - 1-2 months ago - where the answer to this 
problem was to increase the B-tree option to "-B 38[???]", which, at 
that time seemed to have solved the issue. However, that number seemed 
to be *very specific*, and unfortunetaly we "lost" that post.

Example: "mkfs -t nilfs2 *** -B 32768 *** /dev/main_node50G/test/5g" -> 
will fail *later*, but will fail with I/O error "disk full", then 
WITHOUT the *** -B 32768 ***. (Not sure if 32768 is correct. In the 
"lost post" it was 38???, if memory servers.)

Appreciate any help.
Ian

Re: "Drastic I/O error (write(2)): No space left on device"

[Sami Liedes]

[-- Attachment #1.1: Type: text/plain, Size: 2051 bytes --]

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users