Why not just name the cam-ata devices the same as the old names?

Jason J. Hellenthal jhell at DataIX.net
Wed Apr 27 05:42:24 UTC 2011


On Tue, Apr 26, 2011 at 04:47:45PM -0700, Doug Barton wrote:
>On 04/26/2011 16:04, Mikael Fridh wrote:
>> Are labels such a perilous affair that you can't just start
>> recommending them and/or default to them?
>
>As far as I can tell, yes. We have various different tools that do 
>different things, all calling themselves "labels" which don't all work 
>together well. It's also unclear how many (if any) of those solutions 
>will survive the file system being newfs'ed.
>
>I made this point elsewhere, but this is an area where linux really has 
>us beat. At install time a UUID is created for a file system if it 
>doesn't already have one and it's referred to that way in fstab. My 
>understanding (although I have yet to test it) is that they survive 
>newfs because they are not located on the fs itself. When I first saw 
>this I thought it was ugly (read, different) but having worked with it a 
>little bit I think it's a much superior method, and would have made the 
>current concerns completely irrelevant. 
>http://www.linux.com/archive/feature/146951
>

Hi Doug,

I do not know if this was summed up in a easy way by Jeremy's nice
message below but in short a summary can be made here to clear that up.

/dev/gptid/* /dev/gpt/*
	* These survive its raw partition being newfs'd
	* Are only created for disks that are partitioned
	  and contain a GPT table as can be seen with gpart
	  show
	* Operations on these or the raw partition will not remove them.

/dev/ufsid/* /dev/ufs/*
	* Will not survive a newfs
	* Are created upon being newfs'd
	* /dev/ufs/* is the equiv of (tunefs -L)
	* /dev/ufsid/* is only created by newfs(8)
	* Operations on these or the raw slice will not remove them.

/dev/label/*
	* Are created by glabel(8)
	* Will remain with the disk until its raw disk is newfs'd or
	  data overwrites the metadata on the raw disk.
	* When created only the label should be  newfs'd directly as a
	  new on the disk itself would overwrite the metadata stored.
	* Operations on the label itself is only supported to retain the
	  metadata.
	

The best possible thing you could use here is a GPT scheme for the disks
to remain consistent across newfs's. But relying on GPT for all disks
will not always work in situations where the disk also involves a
operating system that does not support booting off of a GPT disk, like
all of Windows XP and then Win7 for non-Itanium based architectures. Yes
Win7 last checked was said to only support booting GPT schemes on
Itanium systems, so this leaves a lot of systems to only rely on
/dev/ufs*/ labels or generic labels.


-- 

 Regards, (jhell)
 Jason Hellenthal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20110427/0985f908/attachment.pgp


More information about the freebsd-fs mailing list