We have not seen any evidence that installs which do not use git-phab experience this problem, nor evidence that the upstream workflow is incompatible with small, clean commits.

I used bin/remove destroy <phid> to destroy the 881 identical diffs, and verified that trimmed roughly 4GB of data out of the datastore.

I think this was caused by the issue resolved by D15072. Specifically:

This should probably happen in the next week, as it's creating moderate storage pressure on db005.

After rCORE538a9808, all new files larger than 64KB go to S3.

This was fixed by D14925.

I can't immediately reproduce this at HEAD but I'll poke around a little bit more.

This does not describe a bug in Phabricator. Please read Support Resources and Contributing Bug Reports carefully.

After D15093, this should be a little better:

After D15093:

(This is definitely confusing, but I'm not sure what the best way forward is offhand. I'm hesitant to just make Herald always trigger without putting more thought into the issue.)

Add a call to ->setPageSize(500) (for whatever value of 500 you prefer) here:

What sort of answer would you prefer we provide?

(See also Contributing Feature Requests and Describing Root Problems, and T8227.)

We don't plan to implement this.

From T10170, Ponder still has some addRawSection() calls which should be addRemarkupSection() calls.

This request does not describe a root problem. See Contributing Feature Requests for details, and Describing Root Problems for help describing a root problem.

The first hit on Google for "phabricator daemons" should be the documentation for them:

This would be ambiguous with other directives (lines, name, counterexample, etc).

We can't reproduce any of this and no other users have reported similar issues. Some of the issues described here are likely access/permissions issues, which should be communicated more clearly after D15079 / D15080.

This is probably because the user you are connecting with does not have permission to access the database.

I think case (1) (and maybe cases (3) and (4)) is resolved at HEAD.

Herald has some very unusual code to preserve control values when you swap the selectors. Generally, the issue is:

HarbormasterBuildTarget->loadArtifact() also probably does a table scan when it doesn't need to, but if that isn't causing any problems I'll leave it alone for now until we hit it for real.

I can't reproduce the second issue; that index should already exist (or bin/storage adjust should create it if it does not). Here it is in the source:

I believe this is fixed at head. Let us know if you're still seeing issues.

(And there are no configuration settings you can change which will possibly impact or resolve it -- it can only be resolved by an upstream fix to the problematic implementation.)

Sorry, I wasn't very clear -- I know exactly why this is happening. It isn't related to configuration or arcanist (it's an implementation issue related to D14970), so I don't need any more information.

Daemons now do both reads and writes, and may need to do reads and writes which are nonlocal in cluster configurations. So I think the pathway forward here must be to expose local disk storage over HTTP with S3-like raw APIs (read, write, delete).

Sounds good.

This is an issue in the implementation, not a configuration issue.

To the best of my current knowledge, there are no actual problems with the Node server (empirically, it is easy to install and maintain, stable, and works well) and no viable pure PHP alternatives anyway, so I have currently have no plans to ever pursue this. See above for a description of the type of new information which could affect these plans.