Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Pawel Jakub Dawidek]

On Mon, Apr 25, 2011 at 08:34:33PM +0300, Alexander Motin wrote:
 I've thought about the process of fixing hardcoded provider names there,
 and it is absolutely not trivial. If we take the symlinking way (patch
 is already posted to current@), I think it will be much easier for
 everybody, and especially users, if I hack all mentioned above GEOM
 classes to ignore adX/adaY difference in provider names. And it should
 perfectly fit into remaining time window.

Could you be more specific what the hack would do exactly?

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com


pgppYnWTQh2id.pgp
Description: PGP signature

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Pawel Jakub Dawidek]

On Mon, Apr 25, 2011 at 12:16:22PM -0700, Garrett Cooper wrote:
 I'd prefer having an UPDATING note with all of the affected areas so that 
 people can understand what needs to change and adjust their systems 
 accordingly. As far as geom based hardcoding is concerned: maybe this can 
 serve as a good lesson of what shouldn't be done and what should be 
 fixed/have a translation layer added for this item?

Hardcoding provider names in metadata is not mistake. It was added to
protect against hacks like the 'c' partition. In the system there might
be serval providers representing exactly same data and hardcoding
provider name allows to choose the proper one.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com


pgpYmjKQaLxPU.pgp
Description: PGP signature

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

On 26.04.2011 10:00, Pawel Jakub Dawidek wrote:

On Mon, Apr 25, 2011 at 08:34:33PM +0300, Alexander Motin wrote:

I've thought about the process of fixing hardcoded provider names there,
and it is absolutely not trivial. If we take the symlinking way (patch
is already posted to current@), I think it will be much easier for
everybody, and especially users, if I hack all mentioned above GEOM
classes to ignore adX/adaY difference in provider names. And it should
perfectly fit into remaining time window.


Could you be more specific what the hack would do exactly?


I would write some comparison function, which would search both names 
for adX/adaY prefixes, if they found on both arguments, trimmed them and 
compared remaining parts.


I think for usual purpose of name hardcoding device name part is less 
important. Comparing partition names part should be enough. The tricky 
part there is to properly identify device part, so I was thinking about 
specific hack for adX/adaY.


--
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Pawel Jakub Dawidek]

On Tue, Apr 26, 2011 at 10:19:55AM +0300, Alexander Motin wrote:
 On 26.04.2011 10:00, Pawel Jakub Dawidek wrote:
 On Mon, Apr 25, 2011 at 08:34:33PM +0300, Alexander Motin wrote:
 I've thought about the process of fixing hardcoded provider names there,
 and it is absolutely not trivial. If we take the symlinking way (patch
 is already posted to current@), I think it will be much easier for
 everybody, and especially users, if I hack all mentioned above GEOM
 classes to ignore adX/adaY difference in provider names. And it should
 perfectly fit into remaining time window.
 
 Could you be more specific what the hack would do exactly?
 
 I would write some comparison function, which would search both
 names for adX/adaY prefixes, if they found on both arguments,
 trimmed them and compared remaining parts.
 
 I think for usual purpose of name hardcoding device name part is
 less important. Comparing partition names part should be enough. The
 tricky part there is to properly identify device part, so I was
 thinking about specific hack for adX/adaY.

I was wondering how would you match X and Y, but this is indeed not
important. So on taste we could do (totally untested):

static bool
provider_name_matches(const char *ppname, const char *hcname)
{

if (strcmp(ppname, hcname) == 0)
return (true);
if (strncmp(hcname, ad, 2) != 0 ||
hcname[2]  '0' || hcname[2]  '9') {
return (false);
}
if (strncmp(ppname, ada, 3) != 0 ||
ppname[3]  '0' || ppname[3]  '9') {
return (false);
}
/* Skip 'ad[0-9]+'. */
hcname += 3;
while (hcname[0] = '0'  hcname[0] = '9')
hcname++;
/* Skip 'ada[0-9]+'.
ppname += 4;
while (ppname[0] = '0'  ppname[0] = '9')
ppname++;

return (strcmp(ppname, hcname) == 0);
}

That could work.

Another possibility I was thinking of was to create GEOM providers for
both names and orphan the other name once one of them is opened for
writing.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com


pgp0hHvc9o0AW.pgp
Description: PGP signature

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

On 26.04.2011 10:35, Pawel Jakub Dawidek wrote:

On Tue, Apr 26, 2011 at 10:19:55AM +0300, Alexander Motin wrote:

On 26.04.2011 10:00, Pawel Jakub Dawidek wrote:

On Mon, Apr 25, 2011 at 08:34:33PM +0300, Alexander Motin wrote:

I've thought about the process of fixing hardcoded provider names there,
and it is absolutely not trivial. If we take the symlinking way (patch
is already posted to current@), I think it will be much easier for
everybody, and especially users, if I hack all mentioned above GEOM
classes to ignore adX/adaY difference in provider names. And it should
perfectly fit into remaining time window.


Could you be more specific what the hack would do exactly?


I would write some comparison function, which would search both
names for adX/adaY prefixes, if they found on both arguments,
trimmed them and compared remaining parts.

I think for usual purpose of name hardcoding device name part is
less important. Comparing partition names part should be enough. The
tricky part there is to properly identify device part, so I was
thinking about specific hack for adX/adaY.


I was wondering how would you match X and Y, but this is indeed not
important. So on taste we could do (totally untested):

static bool
provider_name_matches(const char *ppname, const char *hcname)
{

if (strcmp(ppname, hcname) == 0)
return (true);
if (strncmp(hcname, ad, 2) != 0 ||
hcname[2]  '0' || hcname[2]  '9') {
return (false);
}
if (strncmp(ppname, ada, 3) != 0 ||
ppname[3]  '0' || ppname[3]  '9') {
return (false);
}
/* Skip 'ad[0-9]+'. */
hcname += 3;
while (hcname[0]= '0'  hcname[0]= '9')
hcname++;
/* Skip 'ada[0-9]+'.
ppname += 4;
while (ppname[0]= '0'  ppname[0]= '9')
ppname++;

return (strcmp(ppname, hcname) == 0);
}

That could work.


Yes, I was thinking about something like that. May be just symmetric, so 
it could handle some cases of downgrade.



Another possibility I was thinking of was to create GEOM providers for
both names and orphan the other name once one of them is opened for
writing.


I've even implemented patch (posted on current@) with close idea (I was 
creating extra geom with legacy name), and it will have the same 
problem: if somebody open any partition on the device with the new name, 
all legacy names will become inaccessible (busy), and vice versa. It 
could be not a big problem if it would only be user's choice -- we could 
say just: use one or another, not both. But provider could be chosen 
blindly by some GEOM class, such as glabel, and then it turns into pure 
lottery.


--
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Pawel Jakub Dawidek]

On Tue, Apr 26, 2011 at 10:50:17AM +0300, Alexander Motin wrote:
 On 26.04.2011 10:35, Pawel Jakub Dawidek wrote:
 On Tue, Apr 26, 2011 at 10:19:55AM +0300, Alexander Motin wrote:
 On 26.04.2011 10:00, Pawel Jakub Dawidek wrote:
 On Mon, Apr 25, 2011 at 08:34:33PM +0300, Alexander Motin wrote:
 I've thought about the process of fixing hardcoded provider names there,
 and it is absolutely not trivial. If we take the symlinking way (patch
 is already posted to current@), I think it will be much easier for
 everybody, and especially users, if I hack all mentioned above GEOM
 classes to ignore adX/adaY difference in provider names. And it should
 perfectly fit into remaining time window.
 
 Could you be more specific what the hack would do exactly?
 
 I would write some comparison function, which would search both
 names for adX/adaY prefixes, if they found on both arguments,
 trimmed them and compared remaining parts.
 
 I think for usual purpose of name hardcoding device name part is
 less important. Comparing partition names part should be enough. The
 tricky part there is to properly identify device part, so I was
 thinking about specific hack for adX/adaY.
 
 I was wondering how would you match X and Y, but this is indeed not
 important. So on taste we could do (totally untested):
 
 static bool
 provider_name_matches(const char *ppname, const char *hcname)
 {
 
  if (strcmp(ppname, hcname) == 0)
  return (true);
  if (strncmp(hcname, ad, 2) != 0 ||
  hcname[2]  '0' || hcname[2]  '9') {
  return (false);
  }
  if (strncmp(ppname, ada, 3) != 0 ||
  ppname[3]  '0' || ppname[3]  '9') {
  return (false);
  }
  /* Skip 'ad[0-9]+'. */
  hcname += 3;
  while (hcname[0]= '0'  hcname[0]= '9')
  hcname++;
  /* Skip 'ada[0-9]+'.
  ppname += 4;
  while (ppname[0]= '0'  ppname[0]= '9')
  ppname++;
 
  return (strcmp(ppname, hcname) == 0);
 }
 
 That could work.
 
 Yes, I was thinking about something like that. May be just
 symmetric, so it could handle some cases of downgrade.

Ok, so this will handle hardcoded provider names. I think this is good
enough.

Now, what about fstab? There is a problem to figure out which disk we
booted from once we enter the kernel. I was wondering if we could detect
that someone is trying to mount root which from 'ad[0-9]+X' and
then we could scan all ada[0-9]+X looking for UFS file system and
/etc/fstab in there and / entry which matches vfs.root.mountfrom variable.
This should cover 99% of cases. 1% is for cases where another disk have
identical partitioning scheme and /etc/fstab file. There also might be
cases where someone defines vfs.root.mountfrom in /boot/loader.conf and
doesn't really use /etc/fstab.

 Another possibility I was thinking of was to create GEOM providers for
 both names and orphan the other name once one of them is opened for
 writing.
 
 I've even implemented patch (posted on current@) with close idea (I
 was creating extra geom with legacy name), and it will have the same
 problem: if somebody open any partition on the device with the new
 name, all legacy names will become inaccessible (busy), and vice
 versa. It could be not a big problem if it would only be user's
 choice -- we could say just: use one or another, not both. But
 provider could be chosen blindly by some GEOM class, such as glabel,
 and then it turns into pure lottery.

Good point.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com


pgpbM2D7HFR36.pgp
Description: PGP signature

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

On 26.04.2011 11:02, Pawel Jakub Dawidek wrote:

Now, what about fstab? There is a problem to figure out which disk we
booted from once we enter the kernel. I was wondering if we could detect
that someone is trying to mount root which from 'ad[0-9]+X' and
then we could scan all ada[0-9]+X  looking for UFS file system and
/etc/fstab in there and / entry which matches vfs.root.mountfrom variable.
This should cover 99% of cases. 1% is for cases where another disk have
identical partitioning scheme and /etc/fstab file. There also might be
cases where someone defines vfs.root.mountfrom in /boot/loader.conf and
doesn't really use /etc/fstab.


I think it will be unpredictable. Many disks may have s1a and especially 
s1d.


What do you think about this:
http://docs.freebsd.org/cgi/mid.cgi?4DB54BA9.5050901
? I've found that zpool utility don't likes symbolic links, but except 
this and together with fixing hardcoding problem IMHO it looks not bad.


--
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Pawel Jakub Dawidek]

On Tue, Apr 26, 2011 at 11:18:06AM +0300, Alexander Motin wrote:
 What do you think about this:
 http://docs.freebsd.org/cgi/mid.cgi?4DB54BA9.5050901
 ? I've found that zpool utility don't likes symbolic links, but
 except this and together with fixing hardcoding problem IMHO it
 looks not bad.

It does look good, indeed.

What's the problem with zpool? It should operate on GEOM providers only.
Also, ZFS should not be affected by providers name changes.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com


pgp8kYcbwmlOq.pgp
Description: PGP signature

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

On 26.04.2011 11:34, Pawel Jakub Dawidek wrote:

On Tue, Apr 26, 2011 at 11:18:06AM +0300, Alexander Motin wrote:

What do you think about this:
http://docs.freebsd.org/cgi/mid.cgi?4DB54BA9.5050901
? I've found that zpool utility don't likes symbolic links, but
except this and together with fixing hardcoding problem IMHO it
looks not bad.


It does look good, indeed.

What's the problem with zpool?


make_dev_alias() creates symlink to the original device. After that, 
attempt to do `zpool create test /dev/ad12 /dev/ad13` fails. May be 
because it doesn't resolve symlink and can't find geom with name ad12.



It should operate on GEOM providers only.


OK. If `zpool create` is the only possible problem there, then I think 
we can live with it.


--
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Pawel Jakub Dawidek]

On Tue, Apr 26, 2011 at 11:45:37AM +0300, Alexander Motin wrote:
 On 26.04.2011 11:34, Pawel Jakub Dawidek wrote:
 On Tue, Apr 26, 2011 at 11:18:06AM +0300, Alexander Motin wrote:
 What do you think about this:
 http://docs.freebsd.org/cgi/mid.cgi?4DB54BA9.5050901
 ? I've found that zpool utility don't likes symbolic links, but
 except this and together with fixing hardcoding problem IMHO it
 looks not bad.
 
 It does look good, indeed.
 
 What's the problem with zpool?
 
 make_dev_alias() creates symlink to the original device. After that,
 attempt to do `zpool create test /dev/ad12 /dev/ad13` fails. May be
 because it doesn't resolve symlink and can't find geom with name
 ad12.

IIRC zpool go straight to GEOM providers and doesn't even look into
/dev/. Feel free to ignore this issue. Actually I think it is even
better as people will notice that they should not use legacy names.

 It should operate on GEOM providers only.
 
 OK. If `zpool create` is the only possible problem there, then I
 think we can live with it.

I agree.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com


pgpBFGfj8XmKq.pgp
Description: PGP signature

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Pawel Jakub Dawidek]

On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
 I had been pondering devfs links myself, the problem is that from the rc
 framework they come too late.  If you can add a simple .ko that does it
 programmatically on 9 that would be great.  The problem is that after booting
 the new kernel you don't know whether people had ATA_STATIC on or not, so
 we'd have to go with the defaults, that were in 8.x (and an extra tunable to
 flip the logic maybe)?

We do know that people have ATA_STATIC_ID, because if they don't, this
means they have their custom kernel config which doesn't contain ATA_CAM
and when they will use it next time they recompile their kernel they
will still have /dev/adX entries.

Also, as Alexander already noted, because of all the problems with ATA
naming over the years and for other reasons too, people often hardcode
provider name in various GEOM classes metadata, so symlink won't help.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com


pgphYasTLOfQ1.pgp
Description: PGP signature

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Warner Losh]

On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:

 On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
 I had been pondering devfs links myself, the problem is that from the rc
 framework they come too late.  If you can add a simple .ko that does it
 programmatically on 9 that would be great.  The problem is that after booting
 the new kernel you don't know whether people had ATA_STATIC on or not, so
 we'd have to go with the defaults, that were in 8.x (and an extra tunable to
 flip the logic maybe)?
 
 We do know that people have ATA_STATIC_ID, because if they don't, this
 means they have their custom kernel config which doesn't contain ATA_CAM
 and when they will use it next time they recompile their kernel they
 will still have /dev/adX entries.
 
 Also, as Alexander already noted, because of all the problems with ATA
 naming over the years and for other reasons too, people often hardcode
 provider name in various GEOM classes metadata, so symlink won't help.

Do we have a short list of the places to look?  A lot of this could be done 
with a script that gets run at installworld and boot time to hunt down the old 
cases and report them to the user before they upgrade their kernel (but this 
would mean backing out the GENERIC change for a while to give people a chance 
to upgrade to label-based provisioning...

Warner

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

Warner Losh wrote:
 On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:
 On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
 I had been pondering devfs links myself, the problem is that from the rc
 framework they come too late.  If you can add a simple .ko that does it
 programmatically on 9 that would be great.  The problem is that after 
 booting
 the new kernel you don't know whether people had ATA_STATIC on or not, so
 we'd have to go with the defaults, that were in 8.x (and an extra tunable to
 flip the logic maybe)?
 We do know that people have ATA_STATIC_ID, because if they don't, this
 means they have their custom kernel config which doesn't contain ATA_CAM
 and when they will use it next time they recompile their kernel they
 will still have /dev/adX entries.

 Also, as Alexander already noted, because of all the problems with ATA
 naming over the years and for other reasons too, people often hardcode
 provider name in various GEOM classes metadata, so symlink won't help.
 
 Do we have a short list of the places to look? 

Quick man pages grepping shows that at least gmirror, gstripe, graid3,
gjournal, gvirstor, gconcat, gshsec support provider names hardcoding.
For gmirror and graid3 present status can be obtained by: `gXXX list |
egrep Flags: .*HARDCODED`. For gvirstor, gshsec, gstripe and gconcat:
`gXXX dump adX | egrep Hardcoded provider: ad`. For gjournal:
`gjournal dump adX | egrep hcprovider: ad`.

 A lot of this could be done with a script that gets run at installworld and 
 boot time to hunt down the old cases and report them to the user before they 
 upgrade their kernel (but this would mean backing out the GENERIC change for 
 a while to give people a chance to upgrade to label-based provisioning...

If I understand idea right, independently of how much we delay it, there
will be some people who not updated during that window to get in code
detecting it during boot. Hardly many people of target auditory updating
their systems each month. Same time some checks indeed could be done in
installkernel.

-- 
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Warner Losh]

On Apr 25, 2011, at 10:29 AM, Alexander Motin wrote:

 Warner Losh wrote:
 On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:
 On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
 I had been pondering devfs links myself, the problem is that from the rc
 framework they come too late.  If you can add a simple .ko that does it
 programmatically on 9 that would be great.  The problem is that after 
 booting
 the new kernel you don't know whether people had ATA_STATIC on or not, so
 we'd have to go with the defaults, that were in 8.x (and an extra tunable 
 to
 flip the logic maybe)?
 We do know that people have ATA_STATIC_ID, because if they don't, this
 means they have their custom kernel config which doesn't contain ATA_CAM
 and when they will use it next time they recompile their kernel they
 will still have /dev/adX entries.
 
 Also, as Alexander already noted, because of all the problems with ATA
 naming over the years and for other reasons too, people often hardcode
 provider name in various GEOM classes metadata, so symlink won't help.
 
 Do we have a short list of the places to look? 
 
 Quick man pages grepping shows that at least gmirror, gstripe, graid3,
 gjournal, gvirstor, gconcat, gshsec support provider names hardcoding.
 For gmirror and graid3 present status can be obtained by: `gXXX list |
 egrep Flags: .*HARDCODED`. For gvirstor, gshsec, gstripe and gconcat:
 `gXXX dump adX | egrep Hardcoded provider: ad`. For gjournal:
 `gjournal dump adX | egrep hcprovider: ad`.

That wouldn't be too horrible...

 A lot of this could be done with a script that gets run at installworld and 
 boot time to hunt down the old cases and report them to the user before they 
 upgrade their kernel (but this would mean backing out the GENERIC change for 
 a while to give people a chance to upgrade to label-based provisioning...
 
 If I understand idea right, independently of how much we delay it, there
 will be some people who not updated during that window to get in code
 detecting it during boot. Hardly many people of target auditory updating
 their systems each month. Same time some checks indeed could be done in
 installkernel.

We'd have to delay it at least a month, if not more.  However, the time to have 
done these checks were 8.1ish rather than 9.0 nearing code-freezeish.  I'd 
thought there was going to be better compatibility last year at this time, or 
I'd have pushed this idea harder in the community...

And yes, I'd envisioned installkernel also doing these checks, just to be 
complete and prevent foot-shooting.  At this point, it's all we have.  For the 
9.0 install, we'll likely need to do a subset of this as people import their 
gmirrors created with 8.x...

Warner


 
 -- 
 Alexander Motin
 
 

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

Warner Losh wrote:
 On Apr 25, 2011, at 10:29 AM, Alexander Motin wrote:
 Warner Losh wrote:
 On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:
 On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
 I had been pondering devfs links myself, the problem is that from the rc
 framework they come too late.  If you can add a simple .ko that does it
 programmatically on 9 that would be great.  The problem is that after 
 booting
 the new kernel you don't know whether people had ATA_STATIC on or not, so
 we'd have to go with the defaults, that were in 8.x (and an extra tunable 
 to
 flip the logic maybe)?
 We do know that people have ATA_STATIC_ID, because if they don't, this
 means they have their custom kernel config which doesn't contain ATA_CAM
 and when they will use it next time they recompile their kernel they
 will still have /dev/adX entries.

 Also, as Alexander already noted, because of all the problems with ATA
 naming over the years and for other reasons too, people often hardcode
 provider name in various GEOM classes metadata, so symlink won't help.
 Do we have a short list of the places to look? 
 Quick man pages grepping shows that at least gmirror, gstripe, graid3,
 gjournal, gvirstor, gconcat, gshsec support provider names hardcoding.
 For gmirror and graid3 present status can be obtained by: `gXXX list |
 egrep Flags: .*HARDCODED`. For gvirstor, gshsec, gstripe and gconcat:
 `gXXX dump adX | egrep Hardcoded provider: ad`. For gjournal:
 `gjournal dump adX | egrep hcprovider: ad`.
 
 That wouldn't be too horrible...
 
 A lot of this could be done with a script that gets run at installworld and 
 boot time to hunt down the old cases and report them to the user before 
 they upgrade their kernel (but this would mean backing out the GENERIC 
 change for a while to give people a chance to upgrade to label-based 
 provisioning...
 If I understand idea right, independently of how much we delay it, there
 will be some people who not updated during that window to get in code
 detecting it during boot. Hardly many people of target auditory updating
 their systems each month. Same time some checks indeed could be done in
 installkernel.
 
 We'd have to delay it at least a month, if not more.  However, the time to 
 have done these checks were 8.1ish rather than 9.0 nearing code-freezeish.  
 I'd thought there was going to be better compatibility last year at this 
 time, or I'd have pushed this idea harder in the community...
 
 And yes, I'd envisioned installkernel also doing these checks, just to be 
 complete and prevent foot-shooting.  At this point, it's all we have.  For 
 the 9.0 install, we'll likely need to do a subset of this as people import 
 their gmirrors created with 8.x...

I've thought about the process of fixing hardcoded provider names there,
and it is absolutely not trivial. If we take the symlinking way (patch
is already posted to current@), I think it will be much easier for
everybody, and especially users, if I hack all mentioned above GEOM
classes to ignore adX/adaY difference in provider names. And it should
perfectly fit into remaining time window.

-- 
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[John Baldwin]

On Sunday, April 24, 2011 3:41:08 pm Alexander Motin wrote:
 On 24.04.2011 21:59, Bjoern A. Zeeb wrote:
  What's about creating some kind of symlinks, it could be nice if it
  worked, but I don't see the way to do it on disk(9) or GEOM layers
  without breaking device's access counters and as result further random
  problems.
 
  I had been pondering devfs links myself, the problem is that from the rc
  framework they come too late.  If you can add a simple .ko that does it
  programmatically on 9 that would be great.  The problem is that after 
  booting
  the new kernel you don't know whether people had ATA_STATIC on or not, so
  we'd have to go with the defaults, that were in 8.x (and an extra tunable to
  flip the logic maybe)?
 
 Devfs links won't help users with hardcoded provider names in gmirror, 
 etc -- from GEOM PoV there will be no such providers. Also to create 
 proper mapping that module should have real-time information from CAM 
 about ATA controller details. And looking that it will have to link in 
 real time any derivative providers also (ad4s1a - ada0s1a) I worry if 
 it is possible at all. Some devfs expert needed here.

I think the biggest goal is to make /etc/fstab migration easiest.  I wonder if
you could leverage the device cloning callback in devfs to create symlinks
on the fly as name lookups were done (so if mount tries to use /dev/ad4blah
from /etc/fstab the symlink would be created on the fly).  This would allow
you to handle arbitrary suffixes (i.e. just make sure it matches 'adX(.*)'
and generate 'adaY\1' as the link target) without having to modify any of
gpart, etc. to create a forest of symlinks.

The only possible issue with this is that the devfs cloning eventhandler wants
you to return a dev_t, not a symlink.  That might still work fine (you might
have to do a namei() lookup to find the adaX.* devfs entry), but then you
would not get /dev/adX.* entries listed in /dev when you did an ls.  Instead,
trying to open those old names would just transparently work.  You could maybe
print a message on the console warning that you were remapping an old name to a
new one.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[David O'Brien]

On Sun, Apr 24, 2011 at 08:58:58AM +, Alexander Motin wrote:
 Log:
   Switch the GENERIC kernels for all architectures to the new CAM-based ATA
   stack. It means that all legacy ATA drivers are disabled and replaced by
   respective CAM drivers. If you are using ATA device names in /etc/fstab or
   other places, make sure to update them respectively (adX - adaY,
   acdX - cdY, afdX - daY, astX - saY, where 'Y's are the sequential
   numbers for each type in order of detection, unless configured otherwise
   with tunables, see cam(4)).

I apologize if I missed a past discussion... but wasn't CAM designed
so that all disk-like things would be 'da' (direct access) irregardless
of underling protocol (SCSI/SAS/PATA/SATA)?  afdX - daY above helps
suggest this.  Wasn't that the reason we moved from 'sd' to 'da'?
At least this was the impression on freebsd-current@ back when we when
thru this in 1999 (e.g., 36eff7c2.41c67...@whistle.com,
4714.920569...@verdi.nethelp.no, 29382.921672...@verdi.nethelp.no,
199903172035.paa07...@khavrinen.lcs.mit.edu).


Now ATA-CAM is the default, why aren't disks devices named by the
established CAM names?

If we're not going to call CAM controlled ATA disks da, then why not
keep the existing ad and ar given ad stood for ATA-Disk and
ATA-RAID -- you're still calling the subsystem ata.

Otherwise, we can just recycle email from 1999 where folks didn't
see much value in the sd-da change.

-- 
-- David  (obr...@freebsd.org)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Garrett Cooper]

On Apr 25, 2011, at 9:29 AM, Alexander Motin m...@freebsd.org wrote:

 Warner Losh wrote:
 On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:
 On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
 I had been pondering devfs links myself, the problem is that from the rc
 framework they come too late.  If you can add a simple .ko that does it
 programmatically on 9 that would be great.  The problem is that after 
 booting
 the new kernel you don't know whether people had ATA_STATIC on or not, so
 we'd have to go with the defaults, that were in 8.x (and an extra tunable 
 to
 flip the logic maybe)?
 We do know that people have ATA_STATIC_ID, because if they don't, this
 means they have their custom kernel config which doesn't contain ATA_CAM
 and when they will use it next time they recompile their kernel they
 will still have /dev/adX entries.
 
 Also, as Alexander already noted, because of all the problems with ATA
 naming over the years and for other reasons too, people often hardcode
 provider name in various GEOM classes metadata, so symlink won't help.
 
 Do we have a short list of the places to look? 
 
 Quick man pages grepping shows that at least gmirror, gstripe, graid3,
 gjournal, gvirstor, gconcat, gshsec support provider names hardcoding.
 For gmirror and graid3 present status can be obtained by: `gXXX list |
 egrep Flags: .*HARDCODED`. For gvirstor, gshsec, gstripe and gconcat:
 `gXXX dump adX | egrep Hardcoded provider: ad`. For gjournal:
 `gjournal dump adX | egrep hcprovider: ad`.
 
 A lot of this could be done with a script that gets run at installworld and 
 boot time to hunt down the old cases and report them to the user before they 
 upgrade their kernel (but this would mean backing out the GENERIC change for 
 a while to give people a chance to upgrade to label-based provisioning...
 
 If I understand idea right, independently of how much we delay it, there
 will be some people who not updated during that window to get in code
 detecting it during boot. Hardly many people of target auditory updating
 their systems each month. Same time some checks indeed could be done in
 installkernel.

For people like me who install multiple kernels and boot them at will, 
especially when there are other features under a large degree of development, 
this kind of action isn't acceptable because it shoots you in the foot when 
moving between the different kernels.

I'd prefer having an UPDATING note with all of the affected areas so that 
people can understand what needs to change and adjust their systems 
accordingly. As far as geom based hardcoding is concerned: maybe this can serve 
as a good lesson of what shouldn't be done and what should be fixed/have a 
translation layer added for this item?

Thanks,
-Garrett___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

David O'Brien wrote:
 On Sun, Apr 24, 2011 at 08:58:58AM +, Alexander Motin wrote:
 Log:
   Switch the GENERIC kernels for all architectures to the new CAM-based ATA
   stack. It means that all legacy ATA drivers are disabled and replaced by
   respective CAM drivers. If you are using ATA device names in /etc/fstab or
   other places, make sure to update them respectively (adX - adaY,
   acdX - cdY, afdX - daY, astX - saY, where 'Y's are the sequential
   numbers for each type in order of detection, unless configured otherwise
   with tunables, see cam(4)).
 
 I apologize if I missed a past discussion... but wasn't CAM designed
 so that all disk-like things would be 'da' (direct access) irregardless
 of underling protocol (SCSI/SAS/PATA/SATA)?  afdX - daY above helps
 suggest this.  Wasn't that the reason we moved from 'sd' to 'da'?
 At least this was the impression on freebsd-current@ back when we when
 thru this in 1999 (e.g., 36eff7c2.41c67...@whistle.com,
 4714.920569...@verdi.nethelp.no, 29382.921672...@verdi.nethelp.no,
 199903172035.paa07...@khavrinen.lcs.mit.edu).

CAM unifies the way to execute commands on devices with different
transports. That is why after this change afdX become daY and acdX
become cdY -- they all use SCSI command set. adaX same time stays on
it's own because it is ATA and uses different peripheral driver. It was
one of options to go by emulation way, translating SCSI commands into
ATA. That would turned all direct access devices into SCSI and daX, but
we went other way to not implement additional state machines for this
translation, since existing ata(4) state machine was horrible and we
prefer to drop it completely.

 Now ATA-CAM is the default, why aren't disks devices named by the
 established CAM names?
 
 If we're not going to call CAM controlled ATA disks da, then why not
 keep the existing ad and ar given ad stood for ATA-Disk and
 ATA-RAID -- you're still calling the subsystem ata.

What's about ad and ada, there is about 18 month history of early
adopting this new ATA stack. Using same name initially wasn't possible
due to collisions old stack, change now -- due to many adopted systems.

What's about ar, it is not so principal to me. With new names I was
trying to mimic other GEOMs behavior. But if people decide otherwise, I
see no problem to change it now.

 Otherwise, we can just recycle email from 1999 where folks didn't
 see much value in the sd-da change.

Sorry, I wasn't there in 1990s to speak about that change.

-- 
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Warner Losh]

On Apr 25, 2011, at 1:16 PM, Garrett Cooper wrote:

 On Apr 25, 2011, at 9:29 AM, Alexander Motin m...@freebsd.org wrote:
 
 Warner Losh wrote:
 On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:
 On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
 I had been pondering devfs links myself, the problem is that from the rc
 framework they come too late.  If you can add a simple .ko that does it
 programmatically on 9 that would be great.  The problem is that after 
 booting
 the new kernel you don't know whether people had ATA_STATIC on or not, so
 we'd have to go with the defaults, that were in 8.x (and an extra tunable 
 to
 flip the logic maybe)?
 We do know that people have ATA_STATIC_ID, because if they don't, this
 means they have their custom kernel config which doesn't contain ATA_CAM
 and when they will use it next time they recompile their kernel they
 will still have /dev/adX entries.
 
 Also, as Alexander already noted, because of all the problems with ATA
 naming over the years and for other reasons too, people often hardcode
 provider name in various GEOM classes metadata, so symlink won't help.
 
 Do we have a short list of the places to look? 
 
 Quick man pages grepping shows that at least gmirror, gstripe, graid3,
 gjournal, gvirstor, gconcat, gshsec support provider names hardcoding.
 For gmirror and graid3 present status can be obtained by: `gXXX list |
 egrep Flags: .*HARDCODED`. For gvirstor, gshsec, gstripe and gconcat:
 `gXXX dump adX | egrep Hardcoded provider: ad`. For gjournal:
 `gjournal dump adX | egrep hcprovider: ad`.
 
 A lot of this could be done with a script that gets run at installworld and 
 boot time to hunt down the old cases and report them to the user before 
 they upgrade their kernel (but this would mean backing out the GENERIC 
 change for a while to give people a chance to upgrade to label-based 
 provisioning...
 
 If I understand idea right, independently of how much we delay it, there
 will be some people who not updated during that window to get in code
 detecting it during boot. Hardly many people of target auditory updating
 their systems each month. Same time some checks indeed could be done in
 installkernel.
 
 For people like me who install multiple kernels and boot them at will, 
 especially when there are other features under a large degree of development, 
 this kind of action isn't acceptable because it shoots you in the foot when 
 moving between the different kernels.

No it doesn't.
(a) There will be an override flag, if you really don't want to.  
WITHOUT_FSCK_SANITY_CHECK=t and we're done.
(b) The /dev/ufsid/*,/dev/gpt/*, /dev/ufs/* naming works on both flavors of 
kernel.

 I'd prefer having an UPDATING note with all of the affected areas so that 
 people can understand what needs to change and adjust their systems 
 accordingly. As far as geom based hardcoding is concerned: maybe this can 
 serve as a good lesson of what shouldn't be done and what should be 
 fixed/have a translation layer added for this item?

I'd prefer having it be there also.

Warner

 Thanks,
 -Garrett
 
 

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Bruce Cran]

On Sun, 24 Apr 2011 08:58:58 + (UTC)
Alexander Motin m...@freebsd.org wrote:

 If you are using ATA
 device names in /etc/fstab or other places, make sure to update them
 respectively (adX - adaY, acdX - cdY, afdX - daY, astX - saY,
 where 'Y's are the sequential numbers for each type in order of
 detection, unless configured otherwise with tunables, see cam(4)).

People might expect that if ata(4) numbering starts with ad4, ada4
would be created. However on my machines I've seen ad4 get mapped to
ada0.

-- 
Bruce Cran
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

On 24.04.2011 12:06, Bruce Cran wrote:

On Sun, 24 Apr 2011 08:58:58 + (UTC)
Alexander Motinm...@freebsd.org  wrote:


If you are using ATA
device names in /etc/fstab or other places, make sure to update them
respectively (adX -  adaY, acdX -  cdY, afdX -  daY, astX -  saY,
where 'Y's are the sequential numbers for each type in order of
detection, unless configured otherwise with tunables, see cam(4)).


People might expect that if ata(4) numbering starts with ad4, ada4
would be created. However on my machines I've seen ad4 get mapped to
ada0.


Yes. With sequential I mean from 0 and up. :)

What's about 4, I believe not so many people still remember what does it 
mean, and probably none for whom that reason is important now. :)


--
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Bruce Cran]

On Sun, 24 Apr 2011 12:15:51 +0300
Alexander Motin m...@freebsd.org wrote:

 On 24.04.2011 12:06, Bruce Cran wrote:

  People might expect that if ata(4) numbering starts with ad4, ada4
  would be created. However on my machines I've seen ad4 get mapped to
  ada0.
 
 Yes. With sequential I mean from 0 and up. :)

Sorry I didn't read it properly and sent my reply before I noticed you
said adX - adaY, not adX - adaX.

-- 
Bruce Cran
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Kostik Belousov]

On Sun, Apr 24, 2011 at 08:58:58AM +, Alexander Motin wrote:
 Author: mav
 Date: Sun Apr 24 08:58:58 2011
 New Revision: 220982
 URL: http://svn.freebsd.org/changeset/base/220982
 
 Log:
   Switch the GENERIC kernels for all architectures to the new CAM-based ATA
   stack. It means that all legacy ATA drivers are disabled and replaced by
   respective CAM drivers. If you are using ATA device names in /etc/fstab or
   other places, make sure to update them respectively (adX - adaY,
   acdX - cdY, afdX - daY, astX - saY, where 'Y's are the sequential
   numbers for each type in order of detection, unless configured otherwise
   with tunables, see cam(4)).
   
   ataraid(4) functionality is now supported by the RAID GEOM class.
   To use it you can load geom_raid kernel module and use graid(8) tool
   for management. Instead of /dev/arX device names, use /dev/raid/rX.

How many raid implementations, in particular, stripe and mirror ?
Is gstripe/gmirror merged, or planned to be merged with geom_raid ?
Does it make sense to merge if not yet ?


pgpYTb3HXy10m.pgp
Description: PGP signature

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

On 24.04.2011 13:07, Kostik Belousov wrote:

On Sun, Apr 24, 2011 at 08:58:58AM +, Alexander Motin wrote:

Author: mav
Date: Sun Apr 24 08:58:58 2011
New Revision: 220982
URL: http://svn.freebsd.org/changeset/base/220982

Log:
   Switch the GENERIC kernels for all architectures to the new CAM-based ATA
   stack. It means that all legacy ATA drivers are disabled and replaced by
   respective CAM drivers. If you are using ATA device names in /etc/fstab or
   other places, make sure to update them respectively (adX -  adaY,
   acdX -  cdY, afdX -  daY, astX -  saY, where 'Y's are the sequential
   numbers for each type in order of detection, unless configured otherwise
   with tunables, see cam(4)).

   ataraid(4) functionality is now supported by the RAID GEOM class.
   To use it you can load geom_raid kernel module and use graid(8) tool
   for management. Instead of /dev/arX device names, use /dev/raid/rX.


How many raid implementations, in particular, stripe and mirror ?


Same as before: one out, another in.


Is gstripe/gmirror merged, or planned to be merged with geom_raid ?
Does it make sense to merge if not yet ?


It is definitely possible, but it is not done yet to not put all eggs in 
one basket.


--
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Bjoern A. Zeeb]

On Apr 24, 2011, at 8:58 AM, Alexander Motin wrote:

 Author: mav
 Date: Sun Apr 24 08:58:58 2011
 New Revision: 220982
 URL: http://svn.freebsd.org/changeset/base/220982
 
 Log:
  Switch the GENERIC kernels for all architectures to the new CAM-based ATA
  stack. It means that all legacy ATA drivers are disabled and replaced by
  respective CAM drivers. If you are using ATA device names in /etc/fstab or
  other places, make sure to update them respectively (adX - adaY,
  acdX - cdY, afdX - daY, astX - saY, where 'Y's are the sequential
  numbers for each type in order of detection, unless configured otherwise
  with tunables, see cam(4)).


Are you going to address that on updating magic will make it work within the 
next 2-4 weeks?
If you will not then thanks for screwing 50% of our users and please back this 
out again.



  ataraid(4) functionality is now supported by the RAID GEOM class.
  To use it you can load geom_raid kernel module and use graid(8) tool
  for management. Instead of /dev/arX device names, use /dev/raid/rX.
 
 Modified:
  head/UPDATING
  head/sys/amd64/conf/GENERIC
  head/sys/arm/conf/AVILA
  head/sys/arm/conf/CAMBRIA
  head/sys/arm/conf/CRB
  head/sys/arm/conf/DB-78XXX
  head/sys/arm/conf/DB-88F5XXX
  head/sys/arm/conf/DB-88F6XXX
  head/sys/arm/conf/EP80219
  head/sys/arm/conf/IQ31244
  head/sys/arm/conf/TS7800
  head/sys/conf/NOTES
  head/sys/i386/conf/GENERIC
  head/sys/i386/conf/XBOX
  head/sys/ia64/conf/GENERIC
  head/sys/mips/conf/MALTA
  head/sys/mips/conf/MALTA64
  head/sys/mips/conf/OCTEON1
  head/sys/mips/conf/std.SWARM
  head/sys/mips/malta/std.malta
  head/sys/pc98/conf/GENERIC
  head/sys/powerpc/conf/GENERIC
  head/sys/powerpc/conf/GENERIC64
  head/sys/powerpc/conf/MPC85XX
  head/sys/sparc64/conf/GENERIC
  head/sys/sun4v/conf/GENERIC

-- 
Bjoern A. Zeeb You have to have visions!
 Stop bit received. Insert coin for new address family.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Robert Watson]

On Sun, 24 Apr 2011, Alexander Motin wrote:


Author: mav
Date: Sun Apr 24 08:58:58 2011
New Revision: 220982
URL: http://svn.freebsd.org/changeset/base/220982

Log:
 Switch the GENERIC kernels for all architectures to the new CAM-based ATA
 stack. It means that all legacy ATA drivers are disabled and replaced by
 respective CAM drivers. If you are using ATA device names in /etc/fstab or
 other places, make sure to update them respectively (adX - adaY,
 acdX - cdY, afdX - daY, astX - saY, where 'Y's are the sequential
 numbers for each type in order of detection, unless configured otherwise
 with tunables, see cam(4)).

 ataraid(4) functionality is now supported by the RAID GEOM class.
 To use it you can load geom_raid kernel module and use graid(8) tool
 for management. Instead of /dev/arX device names, use /dev/raid/rX.


I'm very pleased to see a continued movement towards the new ATA code; it 
offers clear benefits to all of our users, and is definitely something we want 
done for 9.0.


Could you say more about the migration strategy for users?  I recall that when 
you proposed throwing this switch, several strategies were discussed (likely 
in combination to handle both the immediate upgrade stumble issue and a 
longer-term migration):


(1) Teach new ata parts to replicate the old naming convention in 99.9% of
cases.  Or some suppport module that creates the required symlinks if
loaded (and we load it by default in 9.0, phasing it out later with
appropriate boot-time warnings for 6-12 months).  Obviously, this would be
best-effort, but if it takes us from a 40% upgrade failure to a 1% upgrade
failure, that's a big deal.

(2) Over time, provide a migration to fstab naming storage targets by volume
ID / name / serial number, rather than by hardware path.  A good long-term
strategy but one that requires changes to the installer, upgrade path,
etc.

(3) Teach freebsd-update/installer/etc to recognise *before* a new kernel is
installed whether the current configuration will require hand-holding.

(4) Thinking pretty hard about the roll-back path to avoid stumbles when
there's a problem following a kernel update.  In the past, linking kernel
feature updates to /etc or userspace updates has caused significant issues
for our users, who reasonably expect to follow our normal install the
kernel, reboot, let it sit for a week path.

What is your plan for implementing some combination of these (or did I miss 
the commits that brought them in already)?  In the past, we've seen upgrade 
path problems dislodge users, and since then, we've grown an increased 
assumption of ease-of-upgrade that can be managed automatically by tools like 
freebsd-update.  Breaking the automated upgrade (and roll-back) path would be 
extremely problematic.


Robert
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

On 24.04.2011 13:20, Bjoern A. Zeeb wrote:

On Apr 24, 2011, at 8:58 AM, Alexander Motin wrote:

Author: mav
Date: Sun Apr 24 08:58:58 2011
New Revision: 220982
URL: http://svn.freebsd.org/changeset/base/220982

Log:
  Switch the GENERIC kernels for all architectures to the new CAM-based ATA
  stack. It means that all legacy ATA drivers are disabled and replaced by
  respective CAM drivers. If you are using ATA device names in /etc/fstab or
  other places, make sure to update them respectively (adX -  adaY,
  acdX -  cdY, afdX -  daY, astX -  saY, where 'Y's are the sequential
  numbers for each type in order of detection, unless configured otherwise
  with tunables, see cam(4)).



Are you going to address that on updating magic will make it work within the 
next 2-4 weeks?


s/ad[0-9]+/ada0/ should fit 90%. A bit more sophisticated script should 
fit most. In what place should I put that magic?



If you will not then thanks for screwing 50% of our users and please back this 
out again.


Reverting is not an option. _Constructive_ propositions are welcome.

--
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Robert Watson]

On Sun, 24 Apr 2011, Alexander Motin wrote:

Are you going to address that on updating magic will make it work within 
the next 2-4 weeks?


s/ad[0-9]+/ada0/ should fit 90%. A bit more sophisticated script should fit 
most. In what place should I put that magic?


If you will not then thanks for screwing 50% of our users and please back 
this out again.


Reverting is not an option. _Constructive_ propositions are welcome.


Hi Mav:

It is the policy of this project that the release engineering team has final 
authority over what ships in a release.  It is entirely within scope to revert 
this change for 9.0 if issues with the upgrade path are not addressed.  My 
hope also that this path can be entirely avoided through a rapid addressing of 
upgrade path issues that have been known (and discussed on the mailing lists 
extensively) since you posted about the work on the public mailing lists.


I agree with Bjoern that it is critical to address these issues in a timely 
manner -- our users depend on reliable and easy upgrades, and it seems (on 
face value) that significant work remains to be done to make that possible. 
Our release is increasingly close, and it's important we keep the tree as 
stable as possible so that merges of other straggling features can go 
uneventfully.


Robert
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Robert Watson]

On Sun, 24 Apr 2011, Robert Watson wrote:

I agree with Bjoern that it is critical to address these issues in a timely 
manner -- our users depend on reliable and easy upgrades, and it seems (on 
face value) that significant work remains to be done to make that possible. 
Our release is increasingly close, and it's important we keep the tree as 
stable as possible so that merges of other straggling features can go 
uneventfully.


Just to follow up on the point: it's very important that the new ATA driver 
see as much testing exposure as possible -- that's one reason why paying close 
attention to the upgrade path.  If we knock users off 9-CURRENT due to upgrade 
problems, then we'll reduce testing for this feature just as much as any 
others.  This is a good reason to resolve the problems as quickly as possible!


Robert
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

On 24.04.2011 14:00, Robert Watson wrote:

On Sun, 24 Apr 2011, Alexander Motin wrote:

Are you going to address that on updating magic will make it work
within the next 2-4 weeks?


s/ad[0-9]+/ada0/ should fit 90%. A bit more sophisticated script
should fit most. In what place should I put that magic?


If you will not then thanks for screwing 50% of our users and please
back this out again.


Reverting is not an option. _Constructive_ propositions are welcome.


It is the policy of this project that the release engineering team has
final authority over what ships in a release. It is entirely within
scope to revert this change for 9.0 if issues with the upgrade path are
not addressed. My hope also that this path can be entirely avoided
through a rapid addressing of upgrade path issues that have been known
(and discussed on the mailing lists extensively) since you posted about
the work on the public mailing lists.

I agree with Bjoern that it is critical to address these issues in a
timely manner -- our users depend on reliable and easy upgrades, and it
seems (on face value) that significant work remains to be done to make
that possible. Our release is increasingly close, and it's important we
keep the tree as stable as possible so that merges of other straggling
features can go uneventfully.


I am asking for excuse if my tone was overly strict. It was not my real 
intention to offend anybody. May be inside I am indeed overreacting a 
bit on proposition to revert with no alternative things that I have put 
my heart into, which are broadly accepted by users, which I announced on 
the list few days ago and got no objections. I am sorry for that.


I do worry about possible complications during migration process. And 
obviously this is not an easy question, as soon as it wasn't solved 
during so much time. I will gladly accept any help or real ideas people 
can provide. I just don't like to feel it my own problem. I am not doing 
it for myself. It would be nice to see some friendly support instead.


Thank you.

--
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

Robert Watson wrote:
 I'm very pleased to see a continued movement towards the new ATA code;
 it offers clear benefits to all of our users, and is definitely
 something we want done for 9.0.
 
 Could you say more about the migration strategy for users?  I recall
 that when you proposed throwing this switch, several strategies were
 discussed (likely in combination to handle both the immediate upgrade
 stumble issue and a longer-term migration):
 
 (1) Teach new ata parts to replicate the old naming convention in 99.9% of
 cases.  Or some suppport module that creates the required symlinks if
 loaded (and we load it by default in 9.0, phasing it out later with
 appropriate boot-time warnings for 6-12 months).  Obviously, this
 would be
 best-effort, but if it takes us from a 40% upgrade failure to a 1%
 upgrade
 failure, that's a big deal.
 
 (2) Over time, provide a migration to fstab naming storage targets by
 volume
 ID / name / serial number, rather than by hardware path.  A good
 long-term
 strategy but one that requires changes to the installer, upgrade path,
 etc.
 
 (3) Teach freebsd-update/installer/etc to recognise *before* a new
 kernel is
 installed whether the current configuration will require hand-holding.
 
 (4) Thinking pretty hard about the roll-back path to avoid stumbles when
 there's a problem following a kernel update.  In the past, linking
 kernel
 feature updates to /etc or userspace updates has caused significant
 issues
 for our users, who reasonably expect to follow our normal install the
 kernel, reboot, let it sit for a week path.
 
 What is your plan for implementing some combination of these (or did I
 miss the commits that brought them in already)?  In the past, we've seen
 upgrade path problems dislodge users, and since then, we've grown an
 increased assumption of ease-of-upgrade that can be managed
 automatically by tools like freebsd-update.  Breaking the automated
 upgrade (and roll-back) path would be extremely problematic.

I was hoping to not expand migration process onto another decade. Many
users already migrated to the new infrastructure on both STABLE and
CURRENT and AFAIK editing fstab was not a major problem for them. Since
the last big discussion of this question about year ago we got graid
implemented and some other things required to keep previous
functionality, that could hold users from migration. Making this commit
now I was prepared to spend few weeks on active bug fixing to minimize
number of further rollback cases. So at this moment device names change
is the last major problem I know. Yes, it was the same year ago, but
there was same discussion as the last week about using labels in fstab,
that equally ended with nothing. :(

What's about creating some kind of symlinks, it could be nice if it
worked, but I don't see the way to do it on disk(9) or GEOM layers
without breaking device's access counters and as result further random
problems.

Looking now on these do or revert demands to keep old device naming,
I'll try to make some hacks to CAM and ada(4) driver to mimic old adX
names. I see it in form of some loader tunable, disabled by default (as
it should be on newly installed systems), but that could be set prior to
upgrade if user doesn't want to bother with device names at that moment.
It should partially hide problem for some time.

Will such solution be acceptable?

-- 
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexey Dokuchaev]

On Sun, Apr 24, 2011 at 06:28:48PM +0300, Alexander Motin wrote:
 What's about creating some kind of symlinks, it could be nice if it
 worked, but I don't see the way to do it on disk(9) or GEOM layers
 without breaking device's access counters and as result further random
 problems.

Speaking on Alexander's side, I'd want to mention that many of our users
had been bitten by obscure adX naming during past years (largely due to
ATA_STATIC_ID option which was probably useful back in times when there
typically was only one IDE controller present in system, but leads to all
sorts of weird ad4-6-8's in recent years) had already migrated to glabel
or GPT labels, to avoid precisely the issues we're talking about here.

./danfe
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Robert N. M. Watson]

On 24 Apr 2011, at 17:32, Alexey Dokuchaev wrote:

 On Sun, Apr 24, 2011 at 06:28:48PM +0300, Alexander Motin wrote:
 What's about creating some kind of symlinks, it could be nice if it
 worked, but I don't see the way to do it on disk(9) or GEOM layers
 without breaking device's access counters and as result further random
 problems.
 
 Speaking on Alexander's side, I'd want to mention that many of our users
 had been bitten by obscure adX naming during past years (largely due to
 ATA_STATIC_ID option which was probably useful back in times when there
 typically was only one IDE controller present in system, but leads to all
 sorts of weird ad4-6-8's in recent years) had already migrated to glabel
 or GPT labels, to avoid precisely the issues we're talking about here.

Yes, the argument is not over whether the change should be made, but how we can 
get it done in time for 9.0-RELEASE in such a way that it minimises disruption 
for our users. Clearly, we need the new AHCI driver as the default in the 
release. But if we make upgrading (and rolling back) significantly harder, that 
hurts us a lot. Ideally, we would have shipped the migration parts in 8.2 so 
that 9.0 was a driver change event, not a device naming model change event 
(easing in the administrative hurdle).

Robert___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Robert N. M. Watson]

On 24 Apr 2011, at 12:49, Alexander Motin wrote:

 Reverting is not an option. _Constructive_ propositions are welcome.
 
 It is the policy of this project that the release engineering team has
 final authority over what ships in a release. It is entirely within
 scope to revert this change for 9.0 if issues with the upgrade path are
 not addressed. My hope also that this path can be entirely avoided
 through a rapid addressing of upgrade path issues that have been known
 (and discussed on the mailing lists extensively) since you posted about
 the work on the public mailing lists.
 
 I agree with Bjoern that it is critical to address these issues in a
 timely manner -- our users depend on reliable and easy upgrades, and it
 seems (on face value) that significant work remains to be done to make
 that possible. Our release is increasingly close, and it's important we
 keep the tree as stable as possible so that merges of other straggling
 features can go uneventfully.
 
 I am asking for excuse if my tone was overly strict. It was not my real 
 intention to offend anybody. May be inside I am indeed overreacting a bit on 
 proposition to revert with no alternative things that I have put my heart 
 into, which are broadly accepted by users, which I announced on the list few 
 days ago and got no objections. I am sorry for that.
 
 I do worry about possible complications during migration process. And 
 obviously this is not an easy question, as soon as it wasn't solved during so 
 much time. I will gladly accept any help or real ideas people can provide. I 
 just don't like to feel it my own problem. I am not doing it for myself. It 
 would be nice to see some friendly support instead.

Let's be clear: Bjoern didn't say you should revert it immediately. He said 
that the migration path needs to be fixed in the next month (2-4 weeks). That 
leaves plenty of time to resolve these issues, which I think the consensus is 
should have been resolved before committing the switch, not after. But given 
that it's in the tree, let's leave it there for now to continue to improve our 
testing exposure, and try to get it fixed as quickly as possible.

Robert___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Bjoern A. Zeeb]

On Apr 24, 2011, at 3:28 PM, Alexander Motin wrote:

 I was hoping to not expand migration process onto another decade. Many
 users already migrated to the new infrastructure on both STABLE and
 CURRENT and AFAIK editing fstab was not a major problem for them.

Do not think that based on the hundred replies on the lists in two years,
that any of the hundreds of thousands of machines you haven't heard of
were migrated. A LOT of people simply run on defaults we provide.


 ... So at this moment device names change
 is the last major problem I know. Yes, it was the same year ago, but
 there was same discussion as the last week about using labels in fstab,
 that equally ended with nothing. :(

I am sorry if I was too direct with the fix it the next weeks or backout
earlier today.

As I had said on current@ I have migrated machines myself and am testing
things where possible and it's a good thing to move to.

As I had also said on current@ we must not screw our users and need
transition magic.  I think a couple of others just didn't repeat what
was said months ago.


 What's about creating some kind of symlinks, it could be nice if it
 worked, but I don't see the way to do it on disk(9) or GEOM layers
 without breaking device's access counters and as result further random
 problems.

I had been pondering devfs links myself, the problem is that from the rc
framework they come too late.  If you can add a simple .ko that does it
programmatically on 9 that would be great.  The problem is that after booting
the new kernel you don't know whether people had ATA_STATIC on or not, so
we'd have to go with the defaults, that were in 8.x (and an extra tunable to
flip the logic maybe)?


 Looking now on these do or revert demands to keep old device naming,
 I'll try to make some hacks to CAM and ada(4) driver to mimic old adX
 names. I see it in form of some loader tunable, disabled by default (as
 it should be on newly installed systems), but that could be set prior to
 upgrade if user doesn't want to bother with device names at that moment.
 It should partially hide problem for some time.

It would need to be in and on by default for the lifetime of 9 as it's not
in the last 8.x release (which would need it the other way round anyway.
MIght it be a good idea to do that as well afterwards providing ada links
on the next 8.x release?).

The user could disable it after the conversion happened though with a tunable
to get rid of the extra /dev/* noise.  We could even check for it being on
and check fstab and warn/pester the user then that he'll need to migrate
(on boot from rc.d, in weekly mails, ...).

If we have both information available (old from the kernel transition code)
and new we could even provide a script to do it.

The reason we might not want to do it automatically is that if the user will
decide to boot kernel.old because the new kernel panics after 2 days, she'll
be facing the new ada entries in fstab with an 8.x kernel and that would not
work either.   So it's a decision users need to make eventually themselves
during the lifetime of 9.x when upgrading from an older release.

 Will such solution be acceptable?

I think any solution will be acceptable if it (mostly) works and gets the
possible fallout rate (significantly) down and thanks a lot for picking it
up now!

Bjoern

PS: And I think you'll find a lot of testers the next days/weeks on current@
when people update their kernels and forgot to read UPDATING or fail to
do the conversion properly.;)

-- 
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Alexander Motin]

On 24.04.2011 21:59, Bjoern A. Zeeb wrote:

What's about creating some kind of symlinks, it could be nice if it
worked, but I don't see the way to do it on disk(9) or GEOM layers
without breaking device's access counters and as result further random
problems.


I had been pondering devfs links myself, the problem is that from the rc
framework they come too late.  If you can add a simple .ko that does it
programmatically on 9 that would be great.  The problem is that after booting
the new kernel you don't know whether people had ATA_STATIC on or not, so
we'd have to go with the defaults, that were in 8.x (and an extra tunable to
flip the logic maybe)?


Devfs links won't help users with hardcoded provider names in gmirror, 
etc -- from GEOM PoV there will be no such providers. Also to create 
proper mapping that module should have real-time information from CAM 
about ATA controller details. And looking that it will have to link in 
real time any derivative providers also (ad4s1a - ada0s1a) I worry if 
it is possible at all. Some devfs expert needed here.



Looking now on these do or revert demands to keep old device naming,
I'll try to make some hacks to CAM and ada(4) driver to mimic old adX
names. I see it in form of some loader tunable, disabled by default (as
it should be on newly installed systems), but that could be set prior to
upgrade if user doesn't want to bother with device names at that moment.
It should partially hide problem for some time.


It would need to be in and on by default for the lifetime of 9 as it's not
in the last 8.x release (which would need it the other way round anyway.
MIght it be a good idea to do that as well afterwards providing ada links
on the next 8.x release?).


I wouldn't like to keep that ugly numbering on by default till the 9.x 
EoL even for new installations. Also remember about number of people 
already using new ATA, for whom requirement to disable that tunable may 
also be uncomfortable.



The user could disable it after the conversion happened though with a tunable
to get rid of the extra /dev/* noise.  We could even check for it being on
and check fstab and warn/pester the user then that he'll need to migrate
(on boot from rc.d, in weekly mails, ...).


It would be fine if it was just devfs noise, but I have some doubts 
about it (above).



If we have both information available (old from the kernel transition code)
and new we could even provide a script to do it.

The reason we might not want to do it automatically is that if the user will
decide to boot kernel.old because the new kernel panics after 2 days, she'll
be facing the new ada entries in fstab with an 8.x kernel and that would not
work either.   So it's a decision users need to make eventually themselves
during the lifetime of 9.x when upgrading from an older release.


Reasonable.


Will such solution be acceptable?


I think any solution will be acceptable if it (mostly) works and gets the
possible fallout rate (significantly) down and thanks a lot for picking it
up now!


But that solution should not include setting tunables before upgrading? 
Can't we teach mergemaster or whatever else to set it depending on whet 
disks are now present in system?



PS: And I think you'll find a lot of testers the next days/weeks on current@
when people update their kernels and forgot to read UPDATING or fail to
do the conversion properly.;)


I can always say: read UPDATING (for log: I am not completely serious 
here. :)).


--
Alexander Motin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Warner Losh]

Now that the horse is out of the barn, the following might be a little late 
(unless we unpull the trigger for a month).

But what if we warned that / was on a device name, and not on a 'named' device. 
 Complain if it was on /dev/da0, but not if it was on /dev/ufs/fred-root.

Users would see this warning and react.

Next best thing: make installkernel check for devices on /dev/adX and refuse to 
install the kernel if they are (unless REALLY_THIS_IS_RIGHT is defined :).

This won't help the binary upgrader, but will prevent massive footshooting in 
the mean time.

Warner

On Apr 24, 2011, at 1:41 PM, Alexander Motin wrote:

 On 24.04.2011 21:59, Bjoern A. Zeeb wrote:
 What's about creating some kind of symlinks, it could be nice if it
 worked, but I don't see the way to do it on disk(9) or GEOM layers
 without breaking device's access counters and as result further random
 problems.
 
 I had been pondering devfs links myself, the problem is that from the rc
 framework they come too late.  If you can add a simple .ko that does it
 programmatically on 9 that would be great.  The problem is that after booting
 the new kernel you don't know whether people had ATA_STATIC on or not, so
 we'd have to go with the defaults, that were in 8.x (and an extra tunable to
 flip the logic maybe)?
 
 Devfs links won't help users with hardcoded provider names in gmirror, etc -- 
 from GEOM PoV there will be no such providers. Also to create proper mapping 
 that module should have real-time information from CAM about ATA controller 
 details. And looking that it will have to link in real time any derivative 
 providers also (ad4s1a - ada0s1a) I worry if it is possible at all. Some 
 devfs expert needed here.
 
 Looking now on these do or revert demands to keep old device naming,
 I'll try to make some hacks to CAM and ada(4) driver to mimic old adX
 names. I see it in form of some loader tunable, disabled by default (as
 it should be on newly installed systems), but that could be set prior to
 upgrade if user doesn't want to bother with device names at that moment.
 It should partially hide problem for some time.
 
 It would need to be in and on by default for the lifetime of 9 as it's not
 in the last 8.x release (which would need it the other way round anyway.
 MIght it be a good idea to do that as well afterwards providing ada links
 on the next 8.x release?).
 
 I wouldn't like to keep that ugly numbering on by default till the 9.x EoL 
 even for new installations. Also remember about number of people already 
 using new ATA, for whom requirement to disable that tunable may also be 
 uncomfortable.
 
 The user could disable it after the conversion happened though with a tunable
 to get rid of the extra /dev/* noise.  We could even check for it being on
 and check fstab and warn/pester the user then that he'll need to migrate
 (on boot from rc.d, in weekly mails, ...).
 
 It would be fine if it was just devfs noise, but I have some doubts about it 
 (above).
 
 If we have both information available (old from the kernel transition code)
 and new we could even provide a script to do it.
 
 The reason we might not want to do it automatically is that if the user will
 decide to boot kernel.old because the new kernel panics after 2 days, she'll
 be facing the new ada entries in fstab with an 8.x kernel and that would not
 work either.   So it's a decision users need to make eventually themselves
 during the lifetime of 9.x when upgrading from an older release.
 
 Reasonable.
 
 Will such solution be acceptable?
 
 I think any solution will be acceptable if it (mostly) works and gets the
 possible fallout rate (significantly) down and thanks a lot for picking it
 up now!
 
 But that solution should not include setting tunables before upgrading? Can't 
 we teach mergemaster or whatever else to set it depending on whet disks are 
 now present in system?
 
 PS: And I think you'll find a lot of testers the next days/weeks on current@
 when people update their kernels and forgot to read UPDATING or fail to
 do the conversion properly.;)
 
 I can always say: read UPDATING (for log: I am not completely serious here. 
 :)).
 
 -- 
 Alexander Motin
 
 

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org