Ethan Quach wrote: > > > Evan Layton wrote: >> Not really, 2904 is for adding an enhancement for an option that will >> show the mountpoint property for a BE that is not mounted and to be able >> to show if the BE is currently mounted or not. Right now if a BE is not >> mounted we show a "-" for the mountpoint and not the current value of >> the mountpoint property. >> >> For 4735 the BE in question is activated, mounted and then booted. The >> fact that it was mounted and not unmounted before being booted is more >> related to 1156. > > That is indeed what caused the user to get into this scenario (which > is a separate issue from 2904), but it wasn't clear to me that that's what > the complaint was about. > > The text in 4735 should be cleared up then. The defect reads: > > "beadm list -a" and "zfs list" are inconsistent about mountpoint > after reboot if a BE was mounted before the reboot.
Yes 4735 does need a little cleaning. > > which sounds to me like a simple request that the 'mountpoint' > column from beadm and from zfs are don't show the same > information. Correct they don't show the same information because the mount point property in zfs and the actual mount point being used differ. What is getting reported by beadm is correct in that it is showing where the BE is currently mounted not it's mountpoint property. Based on this beadm and llibbe are correct in what they are doing since they are meant to show the current mountpoint. However it's ZFS that's showing the inconsistency since it's mountpoint property doesn't match where it's actually mounted. > >> The fact that is shows "/" as the mount point is >> because of the changes for ZFS boot and mounting root in the kernel on >> bootup. With these ZFS changes the root dataset for the BE is always >> mounted at "/" no matter what the mountpoint property is set to. > > How does that impact what's seen in the beadm list output though? > Recall, we decided to change what beadm list displays in the > 'mountpoint' column in the beadm list output after the May release. > In 2008.05, it was exactly whatever the mountpoint property was > in zfs. Since then, we've changed to show where the dataset is > truly mounted (if its mounted), and a "-" if its not mounted at all. As part of those changes the code in be_list was changed so that it uses zfs_is_mounted() to check to see if the dataset is mounted. If it's mounted the mount point will be filled in by that call and in this case it's mounted at "/" which is what we report back. However because the BE was not unmounted it's mountpoint property is still set to "/mnt" in spite of the fact that it's really mounted at "/". > >> >> I was talking with Lori on Friday about this issue and it's one that >> exists in snv (with LU) as well. What the ZFS team is thinking about is >> a way to add a temporary mount point property that is not kept across a >> reboot. With this change the BE could be mounted at a temporary mount >> point but on reboot the persistent mount point would be used. > > Theres been talk about this for some time now. Was there any > indication in your conversation that its actually going to get > worked on soon? Yes Lori indicated that they were looking at a fix in the near future but I don't know exactly when. I will see if I can narrow down the time frame for this. Thanks, -evan > > > thanks, > -ethan >> >> -evan >> >> Ethan Quach wrote: >>> The issue in 4735 seems to be more along the lines of 2904 than 1156. >>> i.e. That additional mountpoint display requested in 2904 always be >>> consistent with what zfs shows as the mountpoint. >>> >>> >>> -ethan >>> >>> >>> Jason Zhao wrote: >>>> Hi, Evan: >>>> >>>> In RC2, I could still hit bug 4735 which was marked as duplicate of >>>> 1156. >>>> Since 1156 is closed as WONTFIX, and obviously it is not a libbe >>>> bug. From >>>> your comment, it seems like it is the ZFS boot bug. Do you know the >>>> bug ID >>>> in bugster which can cover the bug, if there is not, I would like to >>>> file a >>>> bug. >>>> >>>> Thanks >>>> Jason >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> caiman-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>> >> >> >> >>
