From 9178019bc3dbfe19c3c8f925a61d9791386322ba Mon Sep 17 00:00:00 2001 From: zardoz Date: Tue, 15 Jul 2014 07:29:37 +0000 Subject: [PATCH] Added a comment --- ..._1133795276371c86cdd52b25a8b20c52._comment | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_3_1133795276371c86cdd52b25a8b20c52._comment diff --git a/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_3_1133795276371c86cdd52b25a8b20c52._comment b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_3_1133795276371c86cdd52b25a8b20c52._comment new file mode 100644 index 0000000000..6b875932d0 --- /dev/null +++ b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_3_1133795276371c86cdd52b25a8b20c52._comment @@ -0,0 +1,28 @@ +[[!comment format=mdwn + username="zardoz" + ip="134.147.14.84" + subject="comment 3" + date="2014-07-15T07:29:37Z" + content=""" +The ext-community seems to +[corroborate](http://www.redhat.com/archives/ext3-users/2013-March/msg00007.html) +the observation that having many sparse directories scales extremely +poorly, though this still leaves me curious as to how btrfs deals +with. + +One thing I read is that btrfs stores a secondary index on directories +and uses this index in the readdir() syscall; this secondary index +works in such a way that inodes are likely to be traversed in +sequential on-disk order, while for ext, the readdir() results will be +ordered by inode number, yielding a random access pattern. + +I must confess I’ve always liked to think of the file-system as a +cheap data-base, but apparently that is not such a good idea (i. e., +it’s not cheap at all, in the long run). On the other hand (supposing +that operations like «git annex unused» do indeed work by traversing +the object tree), it probably wouldn’t be easy coming up with a scheme +that scales better. For traversal-bound operations, one might maintain +a database, but it would be a hassle to ensure that this in always in +sync with the file-system. + +"""]]