On 07/12/2010 09:07 PM, William A. (Andy) Adamson wrote: > On Mon, Jul 12, 2010 at 1:07 PM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: >> > >> > And is this a layoutdriver specific? It looks like generic business only. > > The file layout driver zero's the stripe unit. I anticipate other > fields that would need to be zeroed. > The stripe_unit is per segment surly. It should be set on new segment received. (Again the mix up between layout_type and layout_segment) If stripe_unit also doubles for a flag that says, I have a layout. Then zero it on free_lseg, when identified as last. (Which also means that you are hard coding all-file-layout at heart of files-layout-driver) >> >> As I said above: on_last_segment/remove-from-client-list can call a specific >> free_lo_stateid, could be nice for readability. > > It does: I call pnfs_set_layout_stateid() with the zero_stateid. That > is very clear. > > I just don't see the need for two more states. You might miss-understood me. By state I meant: "a point in code where it is identified that this is first/last segment" This already exists. I did not mean like an NFS4 state machine. I wish we had functions that said _on_first_seg, on_last_seg. But that's just me. > We have a point in the > generic code where the layout segment list is empty. Therefore the > pnfs_layout_type information is stale. Simply initialize and all the > checks we have work. > That is what I meant that I do not like. The initialize should be on first_seg_insert, Not "last_seg_remove in case of re-insert". The only check should be list-is-empty. Then on first insert, all should be initialized. But I guess it's hard to talk about this. Submit the last fixes and I can RFC my approach. I hope when you see it you'll be convinced. Thanks Boaz > -->Andy -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
