Skip to contentSkip to conversation

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

DISCUSSION T-Machine 2 participants 2 messages Jun 23, 2009 1 message not in the archive NILFS2 filesystem

lore
Share & tools
lore

T-Machine

author
#0 lore raw

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 7 lines · 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%.

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

_______________________________________________
users mailing list
[email protected]
https://www.nilfs.org/mailman/listinfo/users