Comments below. 

> -----Original Message-----
> From: dave carlson [mailto:community-noreply@qnx.com] 
> Sent: August 5, 2008 10:56 AM
> To: general-filesystems
> Subject: relearn considered harmful :-)
> 
> 
> The io-lbk partition_vfs_relearn() strategy seems kind-of odd.
> 
> for (n = 0, part = table; n < PTABLE_NUM_PARTITIONS; ++n, ++part) {
> 	if (part->os_type == partition->part_info.os_type) {
>         /* got a match: copy into "our" partition.
> 		vfs->vfs_attr.blocksize = 
> rawblk->v_vfs->vfs_attr.blocksize;
> 
> The odd part is for the blk-part vfs case (which this is) is 
> that we know the part_index (and nesting level).  
> 
> So iterating and matching the *very* weak case that our 
> partition id (aka os_type) matches means that you need to 
> have unique partition ids for each partition or have 
> identically one partition (as would be the case with a 
> dos-thumb drive.)

This is the partition relearn handler, so it's running as a result of a
DCMD_BLK_FORCE_RELEARN being sent to /dev/hd0t179 (for example).  That's
why we know the os_type, part_index, etc..  The relearn is, supposedly,
happening because the physical media was removed, and new media
inserted, with a potentially entirely different partition table.  Right
after those lines you've pasted, the code overwrites almost all of the
attributes of the current /dev/hd0t179, with new ones from the partition
table on the media.  The only thing that remains constant is...you got
it...the os_type.

> 
> Wouldn't it make more sense to use the part_index and check 
> to make sure that all the fields are set correctly?  Am I 
> missing a use-case for this iteration?

The part_index could move.  All that we know for sure is that
/dev/hd0t179 (to continue the example) has to be os_type 179.  Perhaps
the new media has it on part_index 1, whereas the old media was
part_index 0.  

> 
> dave
> 
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post11445
> 
>