diff options
author | 2011-03-14 16:12:49 +0000 | |
---|---|---|
committer | 2011-03-14 16:12:49 +0000 | |
commit | 769d2a780d33fda9dd6e3b4242d31edf5ff2e232 (patch) | |
tree | 36394a58a53d4e6643fafb9d04a8bfe8f07536a3 | |
parent | d7ea568f50026ea581b0c91ae97495a4e89609b2 (diff) |
Added a comment
-rw-r--r-- | doc/forum/hashing_objects_directories/comment_1_c55c56076be4f54251b0b7f79f28a607._comment | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/doc/forum/hashing_objects_directories/comment_1_c55c56076be4f54251b0b7f79f28a607._comment b/doc/forum/hashing_objects_directories/comment_1_c55c56076be4f54251b0b7f79f28a607._comment new file mode 100644 index 000000000..3a19310b6 --- /dev/null +++ b/doc/forum/hashing_objects_directories/comment_1_c55c56076be4f54251b0b7f79f28a607._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + nickname="joey" + subject="comment 1" + date="2011-03-14T16:12:49Z" + content=""" +My experience is that modern filesystems are not going to have many issues with tens to hundreds of thousands of items in the directory. However, if a transition does happen for FAT support I will consider adding hashing. Although getting a good balanced hash in general without, say, checksumming the filename and taking part of the checksum, is difficult. + +I prefer to keep all the metadata in the filename, as this eases recovery if the files end up in lost+found. So while \"SHA/\" is a nice workaround for the FAT colon problem, I'll be doing something else. (What I'm not sure yet.) + +There is no point in creating unused hash directories on initialization. If anything, with a bad filesystem that just guarantees worst performance from the beginning.. +"""]] |