Hello!! As you can tell I''m new to this project but I''m looking forward to contributing. Recently I have worked on some patch for the lustre utilies and I''m now looking to the core file system code. For my first dive into the code I''m tackling bug 18539. Of course looking at the code base opened up alot of questions. Looking at what was recommended by Andreas Dilger was to make use of the oscc_flags. The other part of the solution was to bump up the return value of osc_precreate. My first set of questions delas with the places where the oscc_flag is used in some fashion. I noticed one spot for its use was osc_set_info_async. Looking through the code it appears to be only called by a osc shrink grant which itself appears to happen on a osc disconnect. This is correct or is this function used in other places? The next question is about osc_import_events. Does this function handle events coming from multiple sources, clients, mds, ost? Also are these events the type that are sent out when a state changes versus someone sending a rpc to request the state? My second set of questions deals with osc_statfs*. From the notes in the bugzilla osc_statfs_interpret is a MDS side function. Looking at the code I noticed it is the call back to osc_statfs_async. Knowing that osc_statfs_async is a obd_ops and thus has a wrapper, obd_statfs_async. I scanning the code for this and noticed that this wrapper used with the proper obd_device for the osc was used in the lov layer. The two areas in the lov layer where lov_statfs_async and qos_statfs_update handled this. If I remember right this is on the client side of the code. Where does the mds fit into this? Lov_statfs_async is for when the client queries data about the file. Whereas qos_statfs_update is what is called durning inital file create or when the statfs info is to old. Please correct me if I''m wrong.
Hello! On May 21, 2009, at 10:46 AM, James Simmons wrote:> For my first dive into the code I''m tackling bug 18539. Of course > looking at the code base opened up alot of questions. Looking at > what was > recommended by Andreas Dilger was to make use of the oscc_flags. The > other > part of the solution was to bump up the return value of osc_precreate. > My first set of questions delas with the places where the > oscc_flag is used in some fashion. I noticed one spot for its use was > osc_set_info_async. Looking through the code it appears to be only > called > by a osc shrink grant which itself appears to happen on a osc > disconnect. > This is correct or is this function used in other places? The nextosc_set_info_async (though obd_set_info_async) is used in tons of places.> question is about osc_import_events. Does this function handle events > coming from multiple sources, clients, mds, ost? Also are these events > the type that are sent out when a state changes versus someone > sending a > rpc to request the state?I do not see such function in my tree. osc_import_event on the other hand is generic import state notification, Imports on OSC are only possible from(to) OSTs, so you get notifications in there such as import becoming active/inactive/disconnected/invalid (there is a switch in there that lists all interesting events possible).> > My second set of questions deals with osc_statfs*. From the notes > in the bugzilla osc_statfs_interpret is a MDS side function. Looking > at > the code I noticed it is the call back to osc_statfs_async. Knowing > that osc_statfs_async is a obd_ops and thus has a wrapper, > obd_statfs_async. > I scanning the code for this and noticed that this wrapper used with > the > proper obd_device for the osc was used in the lov layer. The two > areas in > the lov layer where lov_statfs_async and qos_statfs_update handled > this. > If I remember right this is on the client side of the code. Where > does the > mds fit into this? Lov_statfs_async is for when the client queries > dataMDS is a client to OSTs, that''s why it has client bits to deal with them (LOV and OSCs). Bye, Oleg
> > My second set of questions deals with osc_statfs*. From the notes > > in the bugzilla osc_statfs_interpret is a MDS side function. Looking at > > the code I noticed it is the call back to osc_statfs_async. Knowing > > that osc_statfs_async is a obd_ops and thus has a wrapper, obd_statfs_async. > > I scanning the code for this and noticed that this wrapper used with the > > proper obd_device for the osc was used in the lov layer. The two areas in > > the lov layer where lov_statfs_async and qos_statfs_update handled this. > > If I remember right this is on the client side of the code. Where does the > > mds fit into this? Lov_statfs_async is for when the client queries data > > MDS is a client to OSTs, that''s why it has client bits to deal with them > (LOV and OSCs).Because the lov is present also on the MDS as well as the client then the callback, aa->aa_oi->oi_cb_up, is going to depend on it being a MDS or a cleint. Correct or am I wrong?
Hello! On May 22, 2009, at 9:29 AM, James Simmons wrote:>>> My second set of questions deals with osc_statfs*. From the notes >>> in the bugzilla osc_statfs_interpret is a MDS side function. >>> Looking at >>> the code I noticed it is the call back to osc_statfs_async. Knowing >>> that osc_statfs_async is a obd_ops and thus has a wrapper, >>> obd_statfs_async. >>> I scanning the code for this and noticed that this wrapper used >>> with the >>> proper obd_device for the osc was used in the lov layer. The two >>> areas in >>> the lov layer where lov_statfs_async and qos_statfs_update handled >>> this. >>> If I remember right this is on the client side of the code. Where >>> does the >>> mds fit into this? Lov_statfs_async is for when the client queries >>> data >> MDS is a client to OSTs, that''s why it has client bits to deal with >> them >> (LOV and OSCs). > Because the lov is present also on the MDS as well as the client > then the > callback, aa->aa_oi->oi_cb_up, is going to depend on it being a MDS > or a > cleint. Correct or am I wrong?Actually what I see in the code is LOV always assigns the same value, so it should be the same. On the other hand it is a possibility to pass down such a callback from a layer above LOV, then it might be different. Bye, Oleg
On May 21, 2009 15:46 +0100, James Simmons wrote:> For my first dive into the code I''m tackling bug 18539. Of course > looking at the code base opened up alot of questions. Looking at what was > recommended by Andreas Dilger was to make use of the oscc_flags. The other > part of the solution was to bump up the return value of osc_precreate.There are several parts to fixing this bug: 1. have the OSC extract the os_state flags from the obd_statfs struct * this can be done in the osc_statfs_interpret() function, which is registered as the RPC completion callback from osc_statfs_async() - there is the OS_STATE_READONLY which we already return in os_state if the filesystem has detected an error and remounted read-only. This can use a new OSCC_FLAG_RDONLY flag. - the OS_STATE_DEGRADED flag would need to be set for degraded OSTs (see 3.), and should get a new OSCC_FLAG_DEGRADED flag. - the place to hold these returned states is in oscc_flags, which is what the OSC object creation code uses to track its state 2. have the OSC object creation code check for the OSCC_FLAG_RDONLY and OSCC_FLAG_DEGRADED flags. - use OSCC_FLAG_NOSPC as a template for the OSCC_FLAG_RDONLY behaviour, since the code needs to be changed in many of the same places. - current code uses OSCC_FLAG_NOSPC in the case of EROFS returns from object precreation, but this isn''t really correct as OSCC_FLAG_NOSPC is incorrectly cleared in osc_set_info_async when a file is unlinked even if the filesystem is read only. I''m filing a separate bug to fix this issue. - in osc_precreate() it should check for OSCC_FLAG_DEGRADED and also OSCC_FLAG_ROFS and OSCC_FLAG_NOSPC. For ROFS it should treat it like NOSPC (return 1000). For DEGRADED it should return 2 (functional but not preferred for allocation). 3. having the OST notice that the LUN is degraded - add a /proc/fs/lustre/obdfilter/{OST}/degraded file - (separately) we would want to have this automated for MD RAID devices but that doesn''t need to be part of this patch - in statfs it should check for this and return this state via os_state> My first set of questions delas with the places where the > oscc_flag is used in some fashion. I noticed one spot for its use was > osc_set_info_async. Looking through the code it appears to be only called > by a osc shrink grant which itself appears to happen on a osc disconnect. > This is correct or is this function used in other places? The next > question is about osc_import_events. Does this function handle events > coming from multiple sources, clients, mds, ost? Also are these events > the type that are sent out when a state changes versus someone sending a > rpc to request the state? > My second set of questions deals with osc_statfs*. From the notes > in the bugzilla osc_statfs_interpret is a MDS side function. Looking at > the code I noticed it is the call back to osc_statfs_async. Knowing > that osc_statfs_async is a obd_ops and thus has a wrapper, obd_statfs_async. > I scanning the code for this and noticed that this wrapper used with the > proper obd_device for the osc was used in the lov layer. The two areas in > the lov layer where lov_statfs_async and qos_statfs_update handled this. > If I remember right this is on the client side of the code. Where does the > mds fit into this? Lov_statfs_async is for when the client queries data > about the file. Whereas qos_statfs_update is what is called durning > inital file create or when the statfs info is to old. Please correct me if > I''m wrong. > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-develCheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.