Comment From: polarbear567

Hi, @philwebb It will show up like this:

{
  "status":"UP",
  "components": {
    "diskSpace": {
      "status":"UP","
      details": {
        "/etc": {
          "total":499963174912, "free":391009861632
        }, 
        "/bin":{
          "total":499963174912,"free":391009861632
        },
        "threshold":10485760}
  },
  "ping":{"status":"UP"}}}

I don't know what you want to show, but it's completely modifiable, such as the definition of the key in some maps. Maybe you can give some advice?

Comment From: philwebb

In order to remain back compatible we'll probably need to leave the existing "total", "free" and "threshold" values at the root. I think we should probably provide a further breakdown for the individual files. Something like:

{
  "status" : "UP",
  "components" : {
    "diskSpace" : {
      "status" : "UP",
      "details" : {
        "total" : 123,
        "free" : 123,
        "threshold" :123,
        "paths" : {
          "/etc" : {
            "total" : 123,
            "free" : 123
          },
          "/bin" : {
            "total" : 123,
            "free" : 123
          }
        }
    }
 }

Comment From: philwebb

incidentally, I'm afraid we had some issues with the repository over the weekend so you might need to rest your local branch and do a force push. Something like this:

$ git checkout feature/support_multi_disk
$ git reset --hard upstream/master
$ git cherry-pick bb5b359eb6db680baa297f13910d6a9345303e06
$ git push origin feature/support_multi_disk -f

Sorry about that.

Comment From: polarbear567

@philwebb Got it, I'm going to rewrite PR in your format. I'm surprised at the repository issue. I've submitted a branch before, but it's also happening :), and I'll try these git commands you gave me. Thanks for the advice.

Comment From: polarbear567

Hi, @philwebb Now the format will like this:

{
    "status":"UP",
    "components":{
        "diskSpace":{
            "status":"UP",
            "details":{
                "total":499963174912,
                "free":392189550592,
                "threshold":10485760,
                "paths":{
                    "/etc":{
                        "total":499963174912,
                        "free":392189550592
                    },
                    "/bin":{
                        "total":499963174912,
                        "free":392189550592
                    }
                }
            }
        },
        "ping":{
            "status":"UP"
        }
    }
}

When the user opens the port, the project root path to disk information will be displayed by default. If the user configures the management.health.diskspace.path, the path disk information will be displayed under the paths node.

Another question I have is, do we need to consider how users configure project root paths in management.health.diskspace.path (not ".", like this: /Users/xxx/project /yyy/.)? This way, the disk information of the root path will be displayed twice in the result, once under the details node and once under the path node, although I don't think it should cause any misunderstanding.

Comment From: wilkinsona

As suggested by @eddumelendez in https://github.com/spring-projects/spring-boot/issues/18359#issuecomment-537371669, I think we should consider allowing the threshold to be configured on a per-path basis. That'll require a bit of thought to maintain backwards compatibility in the properties.

Comment From: polarbear567

I will continue to fix it here, if you have any good ideas :)

Comment From: mbhave

@polarbear567 Thank you for your work on this PR. We discussed this at length on our team call and it appears that there isn't a good way to support this without making a breaking change. The total, free and threshold keys at the top level do not really mean anything when multiple paths are configured. Those cannot always represent the root path because the user might have configured management.health.diskspace.path to a different value and might not want the root path to contribute to the health status.

Given that this isn't a widely requested feature, we don't think it justifies a breaking change at this time. I'll leave the original issue open so that we can consider it in the future. Thanks again.