Github user eiri commented on the pull request:
https://github.com/apache/couchdb-couch/pull/161#issuecomment-211923314
@davisp I thought there are performance penalty on deleting a lot of files
in deep filesystem hierarchy, I remember @rnewson mentioned this while we've
been discussing how `rename_on_delete` should be done before I started this
implementation. That's why I did urlencode trick to keep the file structure
flat.
Do I understand correctly that you are proposing instead: 1) to change
`rename_on_delete` config parameter for `delete_after_rename` 2) keep doing
what we are doing with renaming files in uuids, moving them in flat fashion in
`.delete` and removing them if `delete_after_rename` set to `true`. 3)
mirroring data directory hierarchy in `.delete` directory, moving there
after-compaction, deleted database and view files and disabling
`init_delete_dir/1` if `delete_after_rename` set to `false`
If this is the case, do you think we should add random suffix to moved
after-compaction files to keep them distinguished? On one hand this could lead
to accumulation of a lot of files in `.delete`, on a flip hand rapid compaction
without suffixing would override previous compactions files that might have
some value.
Should we change config parameter to `rename_instead_of_delete` as @rnewson
proposed, since there are two different ways to rename files and strictly
speaking Couch admin don't necessary need to know how we are deleting files
when we are deleting them for real.
Switching `rename_instead_of_delete` (or `delete_after_rename`) during
Couch life could lead to an interesting state in `.delete` directory - do you
think this is not a concern?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
