On Apr 26, 2011, at 9:00 PM, Nathan Whitehorn wrote: > On 04/26/11 18:48, Daniel O'Connor wrote: >> >> On 26/04/2011, at 1:31, Warner Losh wrote: >>>> This is why I prefer IDs since they are nominally unique (UFS >>>> ones, GPTs damn well better be :) >>>> >>>> Although I concede it is rather annoying to work out which is >>>> which, or type them out manually.. >>> >>> For things like ZFS, UUIDs aren't so bad because it hides them. >> >> Yes, I use GPT with ZFS, it's good :) >> >>> For things like /etc/fstab, I prefer the named approach. This >>> allows me to survive a newfs on a partition if I have to without >>> having to hack my /etc/fstab. I have a large /tmp partition at >>> times, and it gets newfs'd if there's a bad problem... >> >> Yeah, but.. IMHO if the installer supports it then it is dramatically >> less painful.. >> >> I haven't looked to see how hard it is to add, hopefully I will get >> some time to look RSN and it shouldn't be too difficult. > > It's not difficult to add -- the issue is that the mechanism is unreliable. > It doesn't work for all partition types supporting labels, it's hard to > figure out what the name of the label provider is in a generic way, and the > label providers have a nasty habit of disappearing periodically when you use > the underlying provider for anything. Also, retastes don't always work. For > example, if I change the label of a GPT partition, the label provider does > not reflect the change until a disk reattach (e.g. a reboot).
I know that for ufs, it works well, except for the root partition which requires some dancing to retrofit. But if you relabel a partition, it shows up right away in /dev/ufs/newlbl. Guess not all of them are that reliable. The new names, and slightly non-deterministic probe order make it more important that we shake out the bugs from this as best we can. I think that names/uuid are critical to the future, and we need to fix any remaining issues. > If it's a feature that we enable by default, and that the installer relies > upon, it has to work better than that. Thanks for the report. Who are you working with to resolve these issues? Some of them surprise me, but you speak of them as if they are widely known... Without owners, these issues will languish. Warner_______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
