On 13.10.2010 10:29, Stefan Bethke wrote: >> When you are opening provider for writing (i.e. mount FS) GEOM(4) >> initiates SPOILING and all consumers that are attached to this provider >> except one will self-destroyed. When you are closing provider GEOM(4) >> initiates TASTING and consumers can return back. Look at man 4 geom >> for details. > > That explains the mechanism, but not the rationale. Or is it just an > unintended consequence? And how is da2p1 different from ufs/mylabel? > (Mount da2p1 and ufs/mylabel is removed, but not the other way around.)
This is by design. Any provider's entries in /dev are created by GEOM_DEV class. GEOM_PART serves partition tables. GEOM_PART_GPT as part of GEOM_PART serves GPT. GEOM_PART creates new provider for each entry in GPT. For example: da2 has GPT. da2p1 - first entry in GPT. GEOM_PART creates da2p1 provider and GEOM initiate tasting. GEOM_DEV creates new consumer for da2p1 and /dev/da2p1 entry in devfs. At the same time GEOM_LABEL checks this provider and if it found "labels" it creates new consumer and new provider with name ufs/mylabel via slicer interface. After creating new provider GEOM initiate tasting again. And GEOM_DEV creates new consumer and /dev/ufs/mylabel entry. So, now we have two providers through we can get access to one device. But ufs/mylabel's is on top of da2p1. When we do first open one of them for writing GEOM initiate spoiling for protecting from stale metadata. When we do open da2p1 then GEOM_LABEL receives spoil event and destroys own provider. If I'm wrong Pawel can correct me. -- WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
