<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 4:20 PM Andreas Dilger via lustre-devel <<a href="mailto:lustre-devel@lists.lustre.org">lustre-devel@lists.lustre.org</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">On Nov 4, 2025, at 4:42 PM, Jinshan Xiong wrote:<br>
> On Nov 4, 2025, at 15:07, Andreas Dilger <<a href="mailto:adilger@ddn.com" target="_blank">adilger@ddn.com</a>> wrote:<br>
>> Timothy Day <<a href="mailto:timday@amazon.com" target="_blank">timday@amazon.com</a>> wrote:<br>
>>> Overall, I think the concept is interesting. It reminds me of how<br>
>>> Bcachefs handle multi-device support. Each device can be<br>
>>> designated as holding metadata or data replicas. And you<br>
>>> can control the promotion and migration between different<br>
>>> targets (all managed by a migration daemon). But this design is<br>
>>> too limited, IMHO. If we're going to accept the additional complexity<br>
>>> in the OSD, the solution has to be extensible. What if I want to<br>
>>> replicate to multiple targets? What if I want more than two tiers?<br>
>>> What if I want to transparently migrate data from one spill device to<br>
>>> another? We don't need this for the initial implementation, sure.<br>
>>> But these seem like natural extensions.<br>
> <br>
> It’s possible to extend the design to have multiple spill devices in the OSD; you could have two spill devices and mirror them, or raid0 to make a larger device. I don’t see the design would not allow you to do that.<br>
> <br>
>> This is essentially replicating Lustre file layouts in the end, which<br>
>> was my original suggestion - to use FLR and/or PCC-RO foreign<br>
>> mirror layouts for this, even if it is not directly accessible from<br>
>> clients.  That avoids reimplementing tools/formats that already<br>
>> exist in Lustre today for relatively little benefit.<br>
> <br>
> One of the goals is to not have a file system-level scanner, which is not good. Otherwise, we can just use FLR-based tiered storage.<br>
<br>
I don't see how the layout xattr format is related to filesystem-level<br>
scanning?  This is "just" the xattr format *STORED ON THE OST OBJECT*,<br>
and it could be handled by direct device-level (OST) scan tools as well.<br></blockquote><div><br></div><div>I see. I initially thought you proposed the spill device would function as a mirror and that the existing software stack would handle it.</div><div><br></div><div>Are we going to store the spilled object's status in the layout? It sounds difficult because you will have to initiate a layout change from the OSTs. I think we still need to store such an xattr locally in the OST object.</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>
This would allow mirrors (FLR), multiple spill devices (multiple FLR<br>
mirrors), concatenated devices (PFL), etc.  It just avoids adding new<br>
formats that need to be parsed, printed, etc.<br>
<br>
Cheers, Andreas<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
lustre-devel mailing list<br>
<a href="mailto:lustre-devel@lists.lustre.org" target="_blank">lustre-devel@lists.lustre.org</a><br>
<a href="http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org" rel="noreferrer" target="_blank">http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org</a><br>
</blockquote></div></div>