Comments on: Another HAMMER change before release https://www.dragonflydigest.com/2008/05/18/another-hammer-change-before-release/ A running description of activity related to DragonFly BSD. Mon, 19 May 2008 04:23:32 +0000 hourly 1 https://wordpress.org/?v=6.9.4 By: Joe "Floid" Kanowitz https://www.dragonflydigest.com/2008/05/18/another-hammer-change-before-release/comment-page-1/#comment-23825 Mon, 19 May 2008 04:23:32 +0000 http://www.shiningsilence.com/dbsdlog/?p=2845#comment-23825 [Although doing the math on that, even assuming a few orders of magnitude improvement on file creation, it’d take well beyond 10,000,000 years to run out of inodes. 64-bit numbers are big, dur.]

]]> By: Joe "Floid" Kanowitz https://www.dragonflydigest.com/2008/05/18/another-hammer-change-before-release/comment-page-1/#comment-23824 Mon, 19 May 2008 04:11:00 +0000 http://www.shiningsilence.com/dbsdlog/?p=2845#comment-23824 Regarding the question about “filesystemizing,” if the pseudo/subfses in that (proposed 32-bit) tag-space can be created on demand, shouldn’t it be possible to mkdir under a new tag, replicate only the desired files into it (preserving inode numbers), and mv that to the desired location?

You’d be limited to doing that once per clean subfs, and need the free disk space, but that wouldn’t be onerous for the example provided.

…

Also, that’d be an escape valve for inode exhaustion, wouldn’t it? (Not that it should be easy to exhaust 64 bit inodes, but maybe with some sort of runaway process…) Some future utility could do the complex job of repacking (with new inode numbers) into a new pseudo/subfs without having to be part of the base FS.

]]>