headers
dfilter service | 2 Aug 2010 12:40
Picon
Favicon

Re: kern/148540: commit references a PR

The following reply was made to PR kern/148540; it has been noted by GNATS.

From: dfilter <at> FreeBSD.ORG (dfilter service)
To: bug-followup <at> FreeBSD.org
Cc:  
Subject: Re: kern/148540: commit references a PR
Date: Mon,  2 Aug 2010 10:31:02 +0000 (UTC)

 Author: ae
 Date: Mon Aug  2 10:30:49 2010
 New Revision: 210747
 URL: http://svn.freebsd.org/changeset/base/210747

 Log:
   Forward ioctl requests to original geom.

   PR:		148540
   Silence from:	luigi
   Reviewed by:	pjd
   Approved by:	mav (mentor)
   MFC after:	2 weeks

 Modified:
   head/sys/geom/sched/g_sched.c

 Modified: head/sys/geom/sched/g_sched.c
 ==============================================================================
 --- head/sys/geom/sched/g_sched.c	Mon Aug  2 10:26:15 2010	(r210746)
 +++ head/sys/geom/sched/g_sched.c	Mon Aug  2 10:30:49 2010	(r210747)
  <at>  <at>  -136,6 +136,8  <at>  <at>  static void g_sched_dumpconf(struct sbuf
(Continue reading)

Permalink | Reply | 0 comments |
headers
FreeBSD bugmaster | 2 Aug 2010 13:07
Picon
Favicon

Current problem reports assigned to freebsd-geom <at> FreeBSD.org

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/148540  geom       [geom] geom_sched breaks ata devices
o kern/147852  geom       [geom] [panic] graid3 panic: wrong offset 16384 for se
o kern/147851  geom       [geom] [panic] graid3 panic: g_read_data: invalid leng
o kern/147667  geom       [gmirror] Booting with one component of a gmirror, the
o kern/147664  geom       [geom] [patch] Add the ability to create linux and fat
o kern/145818  geom       [geom] geom_stat_open showing cached information for n
o kern/145042  geom       [geom] System stops booting after printing message "GE
o kern/144962  geom       [geom] panic when accessing GPT disk with a large numb
o kern/144905  geom       [geom][gpart] panic in gpart_ctlreq when unplugging ca
o bin/144521   geom       geom(1) tool parsing non-subclass command broken
o kern/143455  geom       gstripe(8) in RELENG_8 (31st Jan 2010) broken
o kern/142563  geom       [geom] [hang] ioctl freeze in zpool
f kern/142365  geom       [geom] FreeBSD RAID1 (gmirror) is much slower than Lin
o kern/141740  geom       [geom] gjournal(8): g_journal_destroy concurrent error
s kern/141235  geom       [geom_part] 8.0 no longer provides /dev entries for al
o kern/140352  geom       [geom] gjournal + glabel not working
o kern/135898  geom       [geom] Severe filesystem corruption - large files or l
o kern/134922  geom       [gmirror] [panic] kernel panic when use fdisk on disk 
o kern/134113  geom       [geli] Problem setting secondary GELI key
o kern/134044  geom       [geom] gmirror(8) overwrites fs with stale data from r
o kern/133931  geom       [geli] [request] intentionally wrong password to destr
(Continue reading)

Permalink | Reply | 0 comments |
headers
ae | 2 Aug 2010 14:15
Picon
Favicon

Re: kern/148540: [geom] geom_sched breaks ata devices

Synopsis: [geom] geom_sched breaks ata devices

State-Changed-From-To: open->patched
State-Changed-By: ae
State-Changed-When: Mon Aug 2 12:14:52 UTC 2010
State-Changed-Why: 
Patched in head/.

http://www.freebsd.org/cgi/query-pr.cgi?pr=148540
Permalink | Reply | 0 comments |
headers
Pawel Jakub Dawidek | 8 Aug 2010 12:30
Picon
Favicon

Re: glabel "force sectorsize" patch

On Sun, Aug 08, 2010 at 03:57:44AM +0200, Ivan Voras wrote:
> Hi,
> 
> In order to help users having 4k sector drives which the system
> recognizes as 512 byte sector drives, I'm proposing a patch to glabel
> which enables it to use a forced sector size for its native-labeled
> providers. It is naturally only usable with glabel-native labels
> (those created by "glabel label") and not partition and file system
> labels because we cannot add arbitrary new fields to metadata of those
> types.
> 
> The patch is here:
> 
> http://people.freebsd.org/~ivoras/diffs/glabel_ssize.patch
[...]
> This mechanism is a band-aid until there's a better way of dealing
> with 4k drives.

So why do you want to obfuscate glabel with it? For people to start
depend on it? Once we start supporting 4kB sectors what do we do with
such a change? Remove it and decrease version number? What people will
do with providers already labeled this way?

If its temporary, just allow to list providers you want to increase
sector size in /boot/loader.conf. Once we start supporting it properly
people might simply remove it from loader.conf and it should just work.

Glabel is not for that and I don't agree for such obfuscation.

--

--
(Continue reading)

Permalink | Reply | 10 comments |
headers
Ivan Voras | 8 Aug 2010 14:02
Picon
Favicon
Gravatar

Re: glabel "force sectorsize" patch

On 8.8.2010 12:30, Pawel Jakub Dawidek wrote:
> On Sun, Aug 08, 2010 at 03:57:44AM +0200, Ivan Voras wrote:
>> Hi,
>>
>> In order to help users having 4k sector drives which the system
>> recognizes as 512 byte sector drives, I'm proposing a patch to glabel
>> which enables it to use a forced sector size for its native-labeled
>> providers. It is naturally only usable with glabel-native labels
>> (those created by "glabel label") and not partition and file system
>> labels because we cannot add arbitrary new fields to metadata of those
>> types.
>>
>> The patch is here:
>>
>> http://people.freebsd.org/~ivoras/diffs/glabel_ssize.patch
> [...]
>> This mechanism is a band-aid until there's a better way of dealing
>> with 4k drives.
> 
> So why do you want to obfuscate glabel with it? For people to start
> depend on it? Once we start supporting 4kB sectors what do we do with
> such a change? Remove it and decrease version number? What people will
> do with providers already labeled this way?
> 
> If its temporary, just allow to list providers you want to increase
> sector size in /boot/loader.conf. Once we start supporting it properly
> people might simply remove it from loader.conf and it should just work.
> 
> Glabel is not for that and I don't agree for such obfuscation.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Pawel Jakub Dawidek | 8 Aug 2010 14:36
Picon
Favicon

Re: glabel "force sectorsize" patch

On Sun, Aug 08, 2010 at 02:02:17PM +0200, Ivan Voras wrote:
> On 8.8.2010 12:30, Pawel Jakub Dawidek wrote:
> > So why do you want to obfuscate glabel with it? For people to start
> > depend on it? Once we start supporting 4kB sectors what do we do with
> > such a change? Remove it and decrease version number? What people will
> > do with providers already labeled this way?
> > 
> > If its temporary, just allow to list providers you want to increase
> > sector size in /boot/loader.conf. Once we start supporting it properly
> > people might simply remove it from loader.conf and it should just work.
> > 
> > Glabel is not for that and I don't agree for such obfuscation.
> 
> Of course, there are good and bad sides to it. My take on it is that the
> only bad side is that it really isn't glabel's primary function to
> (optionally) fixup geometry, while the good sides are:

It isn't its secondary function either.

> * glabel is in GENERIC and judging by the mailing lists' traffic it is
> one of the better used parts of the system so people are familiar with
> it. It is also already used as a perfectly valid fixup for device
> renaming, making both UFS and ZFS more stable for usage.

That's an excellent argument. But you know what? The em(4) is also in
GENERIC, why not to add it in there?

> * You can't really "make people depend on glabel" both because it is in
> GENERIC and because of it storing metadata in the last sector, making
> the rest of the drive completely usable without it in the event native
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marius Nünnerich | 8 Aug 2010 14:57
Picon
Favicon

Re: glabel "force sectorsize" patch

On Sun, Aug 8, 2010 at 14:02, Ivan Voras <ivoras <at> freebsd.org> wrote:
> On 8.8.2010 12:30, Pawel Jakub Dawidek wrote:
>> On Sun, Aug 08, 2010 at 03:57:44AM +0200, Ivan Voras wrote:
>>> Hi,
>>>
>>> In order to help users having 4k sector drives which the system
>>> recognizes as 512 byte sector drives, I'm proposing a patch to glabel
>>> which enables it to use a forced sector size for its native-labeled
>>> providers. It is naturally only usable with glabel-native labels
>>> (those created by "glabel label") and not partition and file system
>>> labels because we cannot add arbitrary new fields to metadata of those
>>> types.
>>>
>>> The patch is here:
>>>
>>> http://people.freebsd.org/~ivoras/diffs/glabel_ssize.patch
>> [...]
>>> This mechanism is a band-aid until there's a better way of dealing
>>> with 4k drives.
>>
>> So why do you want to obfuscate glabel with it? For people to start
>> depend on it? Once we start supporting 4kB sectors what do we do with
>> such a change? Remove it and decrease version number? What people will
>> do with providers already labeled this way?
>>
>> If its temporary, just allow to list providers you want to increase
>> sector size in /boot/loader.conf. Once we start supporting it properly
>> people might simply remove it from loader.conf and it should just work.
>>
>> Glabel is not for that and I don't agree for such obfuscation.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Pawel Jakub Dawidek | 8 Aug 2010 15:07
Picon
Favicon

Re: glabel "force sectorsize" patch

On Sun, Aug 08, 2010 at 02:57:20PM +0200, Marius Nünnerich wrote:
> On Sun, Aug 8, 2010 at 14:02, Ivan Voras <ivoras <at> freebsd.org> wrote:
> > I'd like to hear comments from the wider audience. In respect with your
> > comment, I will compromise: as 4k sector drives have become available
> > over the counter more than 6 months ago and so far I think this is the
> > first effort to give some support for them, I will commit this patch
> > before 9.0 code freeze only if no other support gets developed.
> 
> I do not like this at all. Even if it's just for the KISS and POLA
> principles. A geom should do one thing and do it right imo.
> Why not write a new geom class that does what you want?

New GEOM class only for sectorsize conversion that can operate on
metadata will be useful, not only to solve this particular problem.
Although keep in mind that if at some point disks will be detected and
presented as 4kB providers to the GEOM, this class won't be able to find
its metadata anymore (as it was stored in the last 512 bytes, not in the
last 4 kilobytes).

--

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd <at> FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
Permalink | Reply | 0 comments |
headers
Ivan Voras | 8 Aug 2010 21:08
Picon
Favicon
Gravatar

Re: glabel "force sectorsize" patch

On 8.8.2010 14:57, Marius Nünnerich wrote:
> On Sun, Aug 8, 2010 at 14:02, Ivan Voras <ivoras <at> freebsd.org> wrote:

>>>> This mechanism is a band-aid until there's a better way of dealing
>>>> with 4k drives.

> I do not like this at all. Even if it's just for the KISS and POLA
> principles. A geom should do one thing and do it right imo.

As the addition will not modify general behaviour of glabel but add a
new feature (which is actually clean and trivial to implement) invisible
to most of the users, I don't think either KISS nor POLA are in any
danger here.

I do agree that it shouldn't be glabel's job to do this but also am
*very* strongly against shipping 9.0 without any support for 4k drives,
and the way I've chosen is the lesser of two evils.

Code and patches by others are of course welcome. I'm hoping this
discussion will trigger someone with experience in the lower levels of
kernel to go and finally add the drive info parsing so it gets solved
the right way :)

> Why not write a new geom class that does what you want?

I'm not against this approach also. Technically, if we go this way, the
new GEOM class will be almost a line-for-line copy-paste of glabel with
this single metadata field added, so I'd rather fold it into glabel.
(Continue reading)

Permalink | Reply | 5 comments |
headers
FreeBSD bugmaster | 9 Aug 2010 13:06
Picon
Favicon

Current problem reports assigned to freebsd-geom <at> FreeBSD.org

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o bin/149215   geom       [panic] gpart(8): Delete linux's slice via Gpart - get
p kern/148540  geom       [geom] geom_sched breaks ata devices
o kern/147852  geom       [geom] [panic] graid3 panic: wrong offset 16384 for se
o kern/147851  geom       [geom] [panic] graid3 panic: g_read_data: invalid leng
o kern/147667  geom       [gmirror] Booting with one component of a gmirror, the
o kern/147664  geom       [geom] [patch] Add the ability to create linux and fat
o kern/145818  geom       [geom] geom_stat_open showing cached information for n
o kern/145042  geom       [geom] System stops booting after printing message "GE
o kern/144962  geom       [geom] panic when accessing GPT disk with a large numb
o kern/144905  geom       [geom][gpart] panic in gpart_ctlreq when unplugging ca
o bin/144521   geom       geom(1) tool parsing non-subclass command broken
o kern/143455  geom       gstripe(8) in RELENG_8 (31st Jan 2010) broken
o kern/142563  geom       [geom] [hang] ioctl freeze in zpool
f kern/142365  geom       [geom] FreeBSD RAID1 (gmirror) is much slower than Lin
o kern/141740  geom       [geom] gjournal(8): g_journal_destroy concurrent error
s kern/141235  geom       [geom_part] 8.0 no longer provides /dev entries for al
o kern/140352  geom       [geom] gjournal + glabel not working
o kern/135898  geom       [geom] Severe filesystem corruption - large files or l
o kern/134922  geom       [gmirror] [panic] kernel panic when use fdisk on disk 
o kern/134113  geom       [geli] Problem setting secondary GELI key
o kern/134044  geom       [geom] gmirror(8) overwrites fs with stale data from r
(Continue reading)

Permalink | Reply | 0 comments |

Gmane