Extending storage search

search.md

More options to search

I propose to do all the following (not everthing at once)

Adding more first-level criteria

We can add driver or transport to drive (which currently supports size and name).

We can add id to partition (which currently supports size, name and number).

And so on for logical volumes names and types, etc.

Adding and and or to combine conditions

It would look like this:

{
  "search": {
    "condition": {
      "and": [
        { "transport": "scsi" },
        { "size": { "less": "1TiB" } }
      ]
    }
  }
 }

An open questions about enums

Let's say I want to check whether the transport is "scsi" or "usb". There is an obvious way that is using or like this:

{
  "search": {
    "condition": {
      "or": [
        { "transport": "scsi" },
        { "transport": "usb" }
      ]
    }
  }
 }

But I wonder whether we should also add a syntax with an array like this:

{
  "search": {
    "condition": {
      "transport": ["scsi", "usb"]
    }
  }
 }

Adding not to invert conditions

Right now, if you want to skip a disk that matches a condition, you need an empty drive entry. For example, let's say you want to make sure USB disks are ignored. I fear then you need something like this:

{
  "storage": {
    "drives": [
      {
        "search": { "condition": { "transport": "usb" } },
        "alias": "thisMatchesTheDisksIWantToIgnore"
      },
      {
        "alias": "thisIsTheRealDriveEntryWithMyConfig"
        "partitions": [{ "search": "*", "delete": true }]
      }
    ],
  }
}

Having not would make this case more natural.

{
  "storage": {
    "drives": [
      {
        "search": { "condition": { "not": { "transport": "usb" } } },
        "alias": "thisIsTheRealDriveEntryWithMyConfig",
        "partitions": [{ "search": "*", "delete": true }]
      }
    ],
  }
}

Having not is also beneficial for filesystems (keep reading).

Checking for filesystems presence or properties

Add a filesystem field that can be true or a condition with type, label, and, or or not.

That is, checking whether the device is formatted:

{
  "search": {
    "condition": {
      "filesystem": true
    }
  }
}

Checking that is not formatted:

{
  "search": {
    "condition": {
      "not": { "filesystem": true }
    }
  }
}

Checking that is formatted as XFS.

{
  "search": {
    "condition": {
      "filesystem": { "type": "xfs" }
    }
  }
}

Checking that is formatted, but not as XFS.

{
  "search": {
    "condition": {
      "filesystem": { "not": { "type": "xfs" } }
    }
  }
}

Checking that is not formatted as XFS.

{
  "search": {
    "condition": {
      "not": { "filesystem": { "type": "xfs" } }
    }
  }
}

Searching with drives by their partitions

Would also work similarly for searching VGs based on their LVs or any other "collection".

It would work by adding a partitions key that can optionally contain min, max or condition. It must contain at least one of them.

If condition is omitted, then it matches any partition. Allows to check for presence.

If both min and max are omitted, then it means "all partitions in the drive".

Checking whether there is any partition.

{
  "search": {
    "condition": {
      "partitions": { "min": 1 }
    }
  }
}

Checking whether there are no partitions.

{
  "search": {
    "condition": {
      "partitions": { "max": 0 }
    }
  }
}

Checking if all partitions are of id "Linux" (I guess it also matches if there are no partitions).

{
  "search": {
    "condition": {
      "partitions": { "condition": { "id": "linux" } }
    }
  }
}

Checking that if does not contain any partition of type "linux".

{
  "search": {
    "condition": {
      "partitions": { "max": 0, "condition": { "id": "linux" } }
    }
  }
}

Checking that it contains at least one partition of type "linux".

{
  "search": {
    "condition": {
      "partitions": { "min": 1, "condition": { "id": "linux" } }
    }
  }
}

Checking that it contains at least one partition that is not "linux".

{
  "search": {
    "condition": {
      "partitions": { "min": 1, "condition": { "not": { "id": "linux" } } }
    }
  }
}

I like it, only one note. Currently the "search" for drives, mds, etc, has these properties: "condition", "max", "sort", "ifNotFound". Maybe we can normalize it, so all the "search" admit "condition", "min", "max", "sort" and "ifNotFound".

Yes. All "search" admits those. But this gist is not about adding new kinds of "search", it is about adding new possibilities to "condition".

I was chatting with Claude about the filesystem search. I was not convinced about using filesystem: true:

I think "any"/"none" is clearer than a boolean, for a few reasons:

• It's self-documenting at the call site: { "filesystem": "any" } reads better than { "filesystem": true }, where a reader has to know that "true" means "is formatted".
• It matches an idiom already in this schema — searchAll uses the string const "*" as a shortcut. String-const shortcuts are an established pattern here.
• "none" gives a direct, positive way to express "not formatted" instead of the double-negative { "not": { "filesystem": true } } from the gist examples.

The one trade-off: it diverges from the gist, which uses true. And "none" technically overlaps with { "not": { "filesystem": "any" } } — but that redundancy is convenience, the same way searchAll: "*" overlaps with an empty condition.

So the filesystem value would be one of three shapes:

• "any" — formatted with any filesystem
• "none" — not formatted
• { ... } — a condition object (type, label, and/or/not), which implies "is formatted and matches these properties"

@ancorgs do you mind if we go with "any"/"none" instead of the boolean?