> ...until the space finally gets used in the LV where it encroaches on the max size of the thin volume. I'll assume that this means "once enough data is writt

> ...until the space finally gets used in the LV where it encroaches on the max size of the thin volume. I'll assume that this means "once enough data is written to the LV to fill the space currently allocated to the thin LV". Do correct me if my assumption is incorrect. Did you disable thin LV monitoring and automated resizing? By default, writes to full thin LVs are delayed until the LV is resized or return a write error if the LV hasn't been resized after (a default of) 60 seconds. In my experience, the automated thin LV resizing worked quickly and painlessly. lvmthin(7) says this about the default behavior: Writes to thin LVs are accepted and queued, with the expectation that pool data space will be extended soon. Once data space is extended, the queued writes will be processed, and the thin pool will return to normal operation. While waiting to be extended, the thin pool will queue writes for up to 60 seconds (the default). If data space has not been extended after this time, the queued writes will return an error to the caller, e.g. the file system. This can result in file system corruption for non-journaled file systems that may require repair. When a thin pool returns errors for writes to a thin LV, any file system is subject to losing unsynced user data. > Also the documentation around adding disks and expanding PVs/VGs/LVs when you have thin volumes is poor to non-existent. What changes with PV and VG management when you have thin LVs? I used thin LVs for a while and found that everything other than the automated resizing seemed to be the same as with "thick" LVs. What did I miss?