headers
Ivan Voras | 8 Aug 03:57
Picon
Favicon

glabel "force sectorsize" patch

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

It's tested with UFS+SU and a forced 4k sector size - apparently there
are no problems here. Here's how a dumpfs output looks like from the
test file system with completely default newfs options (except SU):

magic   19540119 (UFS2) time    Sun Aug  8 03:40:47 2010
superblock location     65536   id      [ 4c5e0ab3 41c7e8d9 ]
ncg     7       size    524287  blocks  514774
bsize   16384   shift   14      mask    0xffffc000
fsize   4096    shift   12      mask    0xfffff000
frag    4       shift   2       fsbtodb 3
minfree 8%      optim   time    symlinklen 120
maxbsize 16384  maxbpg  2048    maxcontig 8     contigsumsize 8
nbfree  128690  ndir    2       nifree  150972  nffree  12
bpg     21567   fpg     86268   ipg     21568   unrefs  0
nindir  2048    inopb   64      maxfilesize     140806241583103
sbsize  4096    cgsize  16384   csaddr  1376    cssize  4096
(Continue reading)

Permalink | Reply |
headers
Pawel Jakub Dawidek | 8 Aug 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 |
headers
Ivan Voras | 8 Aug 14:02
Picon
Favicon

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 |
headers
Pawel Jakub Dawidek | 8 Aug 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 |
headers
Marius Nünnerich | 8 Aug 14:57
Picon

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 |
headers
Pawel Jakub Dawidek | 8 Aug 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 |
headers
Ivan Voras | 8 Aug 21:08
Picon
Favicon

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 |
headers
Marius Nünnerich | 8 Aug 22:07
Picon

Re: glabel "force sectorsize" patch

On Sun, Aug 8, 2010 at 21:08, Ivan Voras <ivoras <at> freebsd.org> wrote:
> 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.

"Adding a new feature" maps directly to KISS, especially if the
feature is in the wrong module.
POLA: I wouldn't guess that a blocksize resizing is hidden in a _part_
of glabel. I am not using the native glabel part at all, just the
named GPT partitions as most of the users seem to prefer nower days
(and I guess will get even more traction after Dan's blog post).

> 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.

I am against workarounds for stupid hardware vendors most of the time.
Especially if it's just a minority, they break pola intentionally and
is fixed easily without this kludge. Afaik if you align your
Partitions to higher values (I use 1MB for example) ufs is not having
(Continue reading)

Permalink | Reply |
headers
Dag-Erling Smørgrav | 9 Aug 10:51
Picon
Gravatar

Re: glabel "force sectorsize" patch

Marius Nünnerich <marius <at> nuenneri.ch> writes:
> I did not think of a new GEOM class that looks like glabel but one
> that has no metadata stored on disk . It is then activated and
> controlled by loader.conf variables. (Maybe like gnop? If I remember
> correctly, I did not take a look at that class for ages).

As you would know if you had followed the discussion about WD EARS
disks, gnop does what you want and is currently the recommended
solution.

I am looking into a permanent solution and would appreciate if people
held off on this for a couple of weeks.

DES
--

-- 
Dag-Erling Smørgrav - des <at> des.no
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Ivan Voras | 9 Aug 12:20
Picon
Favicon

Re: glabel "force sectorsize" patch

On 9 August 2010 10:51, Dag-Erling Smørgrav <des <at> des.no> wrote:
> Marius Nünnerich <marius <at> nuenneri.ch> writes:
>> I did not think of a new GEOM class that looks like glabel but one
>> that has no metadata stored on disk . It is then activated and
>> controlled by loader.conf variables. (Maybe like gnop? If I remember
>> correctly, I did not take a look at that class for ages).
>
> As you would know if you had followed the discussion about WD EARS
> disks, gnop does what you want and is currently the recommended
> solution.

Of course, but gnop as a testing GEOM class, does not save its
metadata, meaning it has to be reconfigured after reboot, etc.

> I am looking into a permanent solution and would appreciate if people
> held off on this for a couple of weeks.

Thank you!
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Dag-Erling Smørgrav | 9 Aug 14:37
Picon
Gravatar

Re: glabel "force sectorsize" patch

Ivan Voras <ivoras <at> freebsd.org> writes:
> Dag-Erling Smørgrav <des <at> des.no> writes:
> > Marius Nünnerich <marius <at> nuenneri.ch> writes:
> > > I did not think of a new GEOM class that looks like glabel but one
> > > that has no metadata stored on disk . It is then activated and
> > > controlled by loader.conf variables. (Maybe like gnop? If I
> > > remember correctly, I did not take a look at that class for ages).
> > As you would know if you had followed the discussion about WD EARS
> > disks, gnop does what you want and is currently the recommended
> > solution.
> Of course, but gnop as a testing GEOM class, does not save its
> metadata, meaning it has to be reconfigured after reboot, etc.

Please read what Marius wrote, which I quoted above.

DES
--

-- 
Dag-Erling Smørgrav - des <at> des.no
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Ivan Voras | 9 Aug 15:59
Picon
Favicon

Re: glabel "force sectorsize" patch

On 9 August 2010 14:37, Dag-Erling Smørgrav <des <at> des.no> wrote:
> Ivan Voras <ivoras <at> freebsd.org> writes:
>> Dag-Erling Smørgrav <des <at> des.no> writes:
>> > Marius Nünnerich <marius <at> nuenneri.ch> writes:
>> > > I did not think of a new GEOM class that looks like glabel but one
>> > > that has no metadata stored on disk . It is then activated and
>> > > controlled by loader.conf variables. (Maybe like gnop? If I
>> > > remember correctly, I did not take a look at that class for ages).
>> > As you would know if you had followed the discussion about WD EARS
>> > disks, gnop does what you want and is currently the recommended
>> > solution.
>> Of course, but gnop as a testing GEOM class, does not save its
>> metadata, meaning it has to be reconfigured after reboot, etc.
>
> Please read what Marius wrote, which I quoted above.

You are right, I skipped that part of his message. Gnop fits that.
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Permalink | Reply |

Gmane