<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Nov 4, 2025 at 3:48 PM Andreas Dilger <<a href="mailto:adilger@dilger.ca">adilger@dilger.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Timothy Day <<a href="mailto:timday@amazon.com" target="_blank">timday@amazon.com</a>> wrote:<br>
>>>> I haven’t seen any mention of failover yet in this conversation (may have missed it), but if the device is truly local, then in failed over configurations the data is inaccessible.  If it’s *not* local, why not just make the device part of the OST or an independent OST?<br>
>>> <br>
>>> It won't be local. Actually, this is designed for the cloud.<br>
>> <br>
>> I don't understand how 'local' is being used. Cloud or not, all of the<br>
>> Lustre client, servers, and backend storage service will be co-located<br>
>> in the same data center. I think Patrick is asking whether the spill<br>
>> device will be physically connected to OSS server, or be provided over<br>
>> something like SAN? Either way, presenting this device as an independent<br>
>> OST brings back the pain of manually managing data placement from the<br>
>> client - which this design is trying to avoid.<br>
>> <br>
>>> We already have tiered storage based on mirroring; however, that still requires clients to move data and a file system level scanner to decide which files move to the cold tier. It's cumbersome to maintain those clients.<br>
>> <br>
>> Agree, it's not ideal.<br>
<br>
Regardless of how the spill device is implemented, there will need to be<br>
some scanning of the front OSD device to find/manage objects to mirror<br>
and release.  This could be done directly on the OST with something like<br>
DDN's lipe_find3 utility, or older scanners like lester, zester, e2scan,<br>
etc. that scan the local ldiskfs block device directly.<br>
<br>
If the overhead of a local Lustre mount on the OSS is problematic, that<br>
seems like something which could/should be fixed?  The local mounts are<br>
already "non-recoverable" so that they do not get an entry in last_rcvd<br>
and their absence does not cause any recovery issues.<br>
<br>
The main issue we've seen with local mountpoints is that this can confuse<br>
HA and prevent Lustre module unloading if they are not taken into account<br>
during cleanup.<br></blockquote><div><br></div><div>You're right. That's actually why we didn't do it in the first place. If an OSS crashes, it will definitely lead to recovery timeout and client eviction.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers, Andreas<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div></div>