Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

freebsd-hackers Digest, Vol 364, Issue 4

1 view
Skip to first unread message

freebsd-hac...@freebsd.org

unread,
Mar 18, 2010, 8:00:16 AM3/18/10
to freebsd...@freebsd.org
Send freebsd-hackers mailing list submissions to
freebsd...@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org

You can reach the person managing the list at
freebsd-ha...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."


Today's Topics:

1. Re: ATA 4K sector issues (Dag-Erling Sm?rgrav)
2. Unicode in Syscons: I'd like to go on (Alexander Churanov)
3. Re: ATA 4K sector issues (Mohacsi Janos)
4. Re: ATA 4K sector issues (Dag-Erling Sm?rgrav)
5. Re: ATA 4K sector issues (Thiago Damas)
6. Re: Drop cache (Stefan Esser)
7. Re: ATA 4K sector issues (Thiago Damas)
8. Re: ATA 4K sector issues (Bruce Cran)
9. Re: ATA 4K sector issues (Olivier Smedts)
10. Re: ATA 4K sector issues (Olivier Smedts)
11. Re: ATA 4K sector issues (Thiago Damas)
12. Re: ATA 4K sector issues (Bruce Cran)
13. Re: ATA 4K sector issues (Dag-Erling Sm?rgrav)
14. Re: ATA 4K sector issues (Thiago Damas)
15. GPIO button and userspace (Alex RAY)
16. Re: GPIO button and userspace (Oleksandr Tymoshenko)
17. Re: ATA 4K sector issues (Matthew Dillon)
18. Re: GPIO button and userspace (Alex RAY)
19. Re: ATA 4K sector issues (Matthew Dillon)
20. Re: ATA 4K sector issues (Thiago Damas)
21. Re: ATA 4K sector issues (Matthew Dillon)
22. Re: flash drive crashes hald on amd64 (Steve Franks)
23. Re: ATA 4K sector issues (Andrew Stesin)
24. Re: ATA 4K sector issues (Thiago Damas)
25. Re: flash drive crashes hald on amd64 (Garrett Cooper)
26. ntfsprogs (Samuel Mart?n Moro)
27. FreeBSD pxeboot installation from redhat
(Anupam Sharma - ERS, HCL Tech)
28. Re: ntfsprogs (Gary Jennejohn)
29. Re: ntfsprogs (Samuel Mart?n Moro)


----------------------------------------------------------------------

Message: 1
Date: Wed, 17 Mar 2010 15:31:49 +0100
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: ATA 4K sector issues
To: Mohacsi Janos <moh...@niif.hu>
Cc: freebsd...@freebsd.org
Message-ID: <86tysf5...@ds4.des.no>
Content-Type: text/plain; charset=utf-8

Mohacsi Janos <moh...@niif.hu> writes:
> What is the situation with ATA 4K dirves in FreeBSD? Are there
> any support for them in fdisk or disklabel?

Hmm, didn't we discuss this already? All we need to do is change the
defaults in fdisk so it rounds partition offsets and sizes to a multiple
of 8 sectors (or 16 for future-proofing) instead of aligning them with
fictitious cylinder boundaries. Bsdlabel, as disklabel is properly
known, already DTRT: by default, the first partition starts at offset
16. Just make sure you specify sizes that are divisible by 8 or 16
blocks (not an issue if you use the M or G suffixes). Sysinstall
operates in megabytes.

DES
--
Dag-Erling Smørgrav - d...@des.no


------------------------------

Message: 2
Date: Wed, 17 Mar 2010 17:34:48 +0300
From: Alexander Churanov <alexande...@gmail.com>
Subject: Unicode in Syscons: I'd like to go on
To: freebsd...@freebsd.org
Message-ID:
<3cb459ed1003170734y21f...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi folks!

Some time ago I was initiating the work on syscons driver ( see
http://wiki.freebsd.org/SysconsUnicodeProject ), then was too busy and my
part of the work stalled for about a year. At present I am going to continue
working on this.

One of my students, Vladislav Soldatov, is willing to continue working on
syscons and fonts with me. I have a branch in Perforce, with mapping from
unicode to 8-bit fonts implemented ( see
http://p4db.freebsd.org/branchView.cgi?BRANCH=syscons%2dutf8 ).

Whom should I contact for:

1) Grant permissions for Vladislav to access the Perforce branch?
2) Discuss the state and the future of the work?
I'd like to ensure that we are not doing the same things with other
engineers and everybody is aware of changes.

Alexander Churanov


------------------------------

Message: 3
Date: Wed, 17 Mar 2010 16:53:14 +0100 (CET)
From: Mohacsi Janos <moh...@niif.hu>
Subject: Re: ATA 4K sector issues
To: Dag-Erling Sm?rgrav <d...@des.no>
Cc: freebsd...@freebsd.org
Message-ID: <alpine.BSF.2.00.1...@mignon.ki.iif.hu>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed


On Wed, 17 Mar 2010, Dag-Erling Sm?rgrav wrote:

> Mohacsi Janos <moh...@niif.hu> writes:
>> What is the situation with ATA 4K dirves in FreeBSD? Are there
>> any support for them in fdisk or disklabel?
>
> Hmm, didn't we discuss this already? All we need to do is change the
> defaults in fdisk so it rounds partition offsets and sizes to a multiple
> of 8 sectors (or 16 for future-proofing) instead of aligning them with
> fictitious cylinder boundaries. Bsdlabel, as disklabel is properly
> known, already DTRT: by default, the first partition starts at offset
> 16. Just make sure you specify sizes that are divisible by 8 or 16
> blocks (not an issue if you use the M or G suffixes). Sysinstall
> operates in megabytes.

Thanks for the information.

------------------------------

Message: 4
Date: Wed, 17 Mar 2010 18:35:30 +0100
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: ATA 4K sector issues
To: Thiago Damas <tda...@gmail.com>
Cc: freebsd...@freebsd.org, Mohacsi Janos <moh...@niif.hu>
Message-ID: <86d3z26...@ds4.des.no>
Content-Type: text/plain; charset=utf-8

Thiago Damas <tda...@gmail.com> writes:
> I had problem with ZFS.

What kind of problem?

DES
--
Dag-Erling Smørgrav - d...@des.no


------------------------------

Message: 5
Date: Wed, 17 Mar 2010 14:47:19 -0300
From: Thiago Damas <tda...@gmail.com>
Subject: Re: ATA 4K sector issues
To: Dag-Erling Sm?rgrav <d...@des.no>
Cc: freebsd...@freebsd.org, Mohacsi Janos <moh...@niif.hu>
Message-ID:
<f8e3d83f1003171047o65a...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Slow performance,slow write speed, high delay per operation (gstat, ms/w)
above 400ms was common, with peaks of 3000ms per write). Tested on two
different machines.
Disks WD10EARS in single disk and mirror configurations.

Thiago


2010/3/17 Dag-Erling Smørgrav <d...@des.no>

> Thiago Damas <tda...@gmail.com> writes:
> > I had problem with ZFS.
>
> What kind of problem?
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no
>


------------------------------

Message: 6
Date: Wed, 17 Mar 2010 15:21:50 +0100
From: Stefan Esser <s...@FreeBSD.org>
Subject: Re: Drop cache
To: freebsd...@freebsd.org
Cc: Pieter de Goeje <pie...@degoeje.nl>, Havacci <hav...@gmail.com>
Message-ID: <4BA0E57E...@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-15

Am 16.03.2010 17:00, schrieb Pieter de Goeje:
> On Monday 15 March 2010 04:33:04 Havacci wrote:
>> How I can drop cache memory of my FreeBSD ? I search a lot about this
>> and don't find anything.
>> In Linux i usualy use this command:
>> sync; echo 3 > /proc/sys/vm/drop_caches
>
> Something comparable can be achieved by unmounting and remounting the test
> filesystem.

It used to be the case, that the cache was flushed early enough
to make the following flush all data for a file-system:

# cd /mount/point
# umount /mount/point

The unmount fails, since PWD is within the file-system to be unmounted.
But the cache has already been flushed by then ...

If the question was not about flushing the cache e.g. for benchmarking
purposes, then I'm not sure that a direct equivalent to the Linux
command exists (not knowing Linux and the exact semantics of drop_caches
in the original message).

Regards, STefan


------------------------------

Message: 7
Date: Wed, 17 Mar 2010 14:34:07 -0300
From: Thiago Damas <tda...@gmail.com>
Subject: Re: ATA 4K sector issues
To: Mohacsi Janos <moh...@niif.hu>
Cc: Dag-Erling Sm?rgrav <d...@des.no>, freebsd...@freebsd.org
Message-ID:
<f8e3d83f1003171034m5e7...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

I had problem with ZFS.
With gnop -S 4096, it works well on /dev/ad{a}X.nop; but I decided to not
use those disks.


2010/3/17 Mohacsi Janos <moh...@niif.hu>

>
>
>
> On Wed, 17 Mar 2010, Dag-Erling Sm?rgrav wrote:
>
> Mohacsi Janos <moh...@niif.hu> writes:
>>
>>> What is the situation with ATA 4K dirves in FreeBSD? Are there
>>> any support for them in fdisk or disklabel?
>>>
>>
>> Hmm, didn't we discuss this already? All we need to do is change the
>> defaults in fdisk so it rounds partition offsets and sizes to a multiple
>> of 8 sectors (or 16 for future-proofing) instead of aligning them with
>> fictitious cylinder boundaries. Bsdlabel, as disklabel is properly
>> known, already DTRT: by default, the first partition starts at offset
>> 16. Just make sure you specify sizes that are divisible by 8 or 16
>> blocks (not an issue if you use the M or G suffixes). Sysinstall
>> operates in megabytes.
>>
>
> Thanks for the information.
>
>
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>


------------------------------

Message: 8
Date: Wed, 17 Mar 2010 18:10:14 +0000
From: Bruce Cran <br...@cran.org.uk>
Subject: Re: ATA 4K sector issues
To: freebsd...@freebsd.org
Cc: Mohacsi Janos <moh...@niif.hu>
Message-ID: <201003171810...@cran.org.uk>
Content-Type: Text/Plain; charset="iso-8859-1"

On Wednesday 17 March 2010 10:16:16 Mohacsi Janos wrote:
> Dear FreeBSD hackers,
> What is the situation with ATA 4K dirves in FreeBSD? Are there any
> support for them in fdisk or disklabel?

# mdconfig -a -f ddfile -S 4096
md0
# fdisk /dev/md0
fdisk: could not detect sector size
# mdconfig -d -u 0
# mdconfig -a -f ddfile -S 1024
md0
# fdisk /dev/md0
******* Working on device /dev/md0 *******
parameters extracted from in-core disklabel are:
cylinders=130 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=130 heads=255 sectors/track=63 (16065 blks/cyl)

fdisk: invalid fdisk partition table found
fdisk: /boot/mbr: length must be a multiple of sector size

So it seems there's still work to do to get fdisk working, but I can't try
gpart since I don't have a real disk.

--
Bruce Cran


------------------------------

Message: 9
Date: Wed, 17 Mar 2010 19:12:01 +0100
From: Olivier Smedts <oli...@gid0.org>
Subject: Re: ATA 4K sector issues
To: Thiago Damas <tda...@gmail.com>
Cc: Dag-Erling Sm?rgrav <d...@des.no>, Mohacsi Janos <moh...@niif.hu>,
freebsd...@freebsd.org
Message-ID:
<367b2c981003171112n785...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

2010/3/17 Thiago Damas <tda...@gmail.com>:
>  I had problem with ZFS.
>  With gnop -S 4096, it works well on /dev/ad{a}X.nop; but I decided to not
> use those disks.

So maybe this was not a ZFS problem but a partition misalignment problem ?

On a properly aligned partition with a physical sector size of 4KB and
a logical sector size of 512 bytes, will ZFS try to use blocksizes of
less than 4KB ? Blocksize in ZFS seems to be dynamic (at least when
not told to use a fixed blocksize), but I didn't see somewhere in the
manpage or Sun's website which minimum blocksize ZFS would use for
small files, and if there is a lower limit on blocksizes to use.

>
>
> 2010/3/17 Mohacsi Janos <moh...@niif.hu>
>
>>
>>
>>
>> On Wed, 17 Mar 2010, Dag-Erling Sm?rgrav wrote:
>>
>>  Mohacsi Janos <moh...@niif.hu> writes:
>>>
>>>> What is the situation with ATA 4K dirves in FreeBSD? Are there
>>>> any support for them in fdisk or disklabel?
>>>>
>>>
>>> Hmm, didn't we discuss this already?  All we need to do is change the
>>> defaults in fdisk so it rounds partition offsets and sizes to a multiple
>>> of 8 sectors (or 16 for future-proofing) instead of aligning them with
>>> fictitious cylinder boundaries.  Bsdlabel, as disklabel is properly
>>> known, already DTRT: by default, the first partition starts at offset
>>> 16.  Just make sure you specify sizes that are divisible by 8 or 16
>>> blocks (not an issue if you use the M or G suffixes).  Sysinstall
>>> operates in megabytes.
>>>
>>
>> Thanks for the information.
>>
>>
>> _______________________________________________
>> freebsd...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>>
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>

--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oli...@gid0.org - against HTML email & vCards X
www: http://www.gid0.org - against proprietary attachments / \

"Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas."


------------------------------

Message: 10
Date: Wed, 17 Mar 2010 19:16:09 +0100
From: Olivier Smedts <oli...@gid0.org>
Subject: Re: ATA 4K sector issues
To: Bruce Cran <br...@cran.org.uk>
Cc: freebsd...@freebsd.org, Mohacsi Janos <moh...@niif.hu>
Message-ID:
<367b2c981003171116v16a...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

2010/3/17 Bruce Cran <br...@cran.org.uk>:
> On Wednesday 17 March 2010 10:16:16 Mohacsi Janos wrote:
>> Dear FreeBSD hackers,
>>       What is the situation with ATA 4K dirves in FreeBSD? Are there any
>> support for them in fdisk or disklabel?
>
> # mdconfig -a -f ddfile -S 4096
> md0
> # fdisk /dev/md0
> fdisk: could not detect sector size
> # mdconfig -d -u 0
> # mdconfig -a -f ddfile -S 1024
> md0
> # fdisk /dev/md0
> ******* Working on device /dev/md0 *******
> parameters extracted from in-core disklabel are:
> cylinders=130 heads=255 sectors/track=63 (16065 blks/cyl)
>
> parameters to be used for BIOS calculations are:
> cylinders=130 heads=255 sectors/track=63 (16065 blks/cyl)
>
> fdisk: invalid fdisk partition table found
> fdisk: /boot/mbr: length must be a multiple of sector size
>
> So it seems there's still work to do to get fdisk working, but I can't try
> gpart since I don't have a real disk.

Why not on geom_md ?
# mdconfig -a -f ddfile -S 4096
# gpart create -s gpt md0
# gpart list md0
Geom name: md0
fwheads: 32
fwsectors: 1
last: 25594
first: 6
entries: 128
scheme: GPT
Consumers:
1. Name: md0
Mediasize: 104857600 (100M)
Sectorsize: 4096
Mode: r0w0e0

Same results with MBR scheme.

>
> --
> Bruce Cran
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>

--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oli...@gid0.org - against HTML email & vCards X
www: http://www.gid0.org - against proprietary attachments / \

"Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas."


------------------------------

Message: 11
Date: Wed, 17 Mar 2010 15:17:58 -0300
From: Thiago Damas <tda...@gmail.com>
Subject: Re: ATA 4K sector issues
To: Olivier Smedts <oli...@gid0.org>
Cc: Dag-Erling Sm?rgrav <d...@des.no>, Mohacsi Janos <moh...@niif.hu>,
freebsd...@freebsd.org
Message-ID:
<f8e3d83f1003171117k20d...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

I tried with gpart, gpt scheme, begining in all block alignments possible,
34, 35, 36, 37, 38, 39 etc
Even 64
gpart create -s gpt ad4
gpart add -s 64 -t freebsd-zfs ad4

With UFS, I previouly did some tests (in portuguese):

Particao sem alinhar inicio
=> 34 1953525101 ad4 GPT (932G)
34 1953525101 1 freebsd-ufs (932G)

newfs -U (padrao -f 2048 -b 16384)
# time tar xfj
/install/releases/i386/8.0-RELEASE/8.0-RELEASE/ports/ports.tgz
2.342u 5.013s 20:35.65 0.5% 64+1091k 6623+2734io 0pf+0w

newfs -U -f 4096 -b 32768
# time tar xfj
/install/releases/i386/8.0-RELEASE/8.0-RELEASE/ports/ports.tgz
2.590u 5.263s 22:06.32 0.5% 63+1087k 10911+1676io 0pf+0w


Particao alinhada em multiplos de 4096 bytes (blocos logicos de 512
bytes, entao, multiplo de 8 blocos)
=> 34 1953525101 ad4 GPT (932G)
34 30 - free - (15K)
64 1953525071 1 freebsd-ufs (932G)

newfs -U (padrao -f 2048 -b 16384)
# time tar xfj
/install/releases/i386/8.0-RELEASE/8.0-RELEASE/ports/ports.tgz
2.392u 5.000s 10:24.15 1.1% 64+1095k 8375+2735io 0pf+0w

newfs -U -f 4096 -b 32768
# time tar xfj
/install/releases/i386/8.0-RELEASE/8.0-RELEASE/ports/ports.tgz
2.547u 5.567s 1:25.50 9.4% 64+1088k 11880+1755io 0pf+0w

On Wed, Mar 17, 2010 at 3:12 PM, Olivier Smedts <oli...@gid0.org> wrote:

> 2010/3/17 Thiago Damas <tda...@gmail.com>:
> > I had problem with ZFS.
> > With gnop -S 4096, it works well on /dev/ad{a}X.nop; but I decided to
> not
> > use those disks.
>
> So maybe this was not a ZFS problem but a partition misalignment problem ?
>
> On a properly aligned partition with a physical sector size of 4KB and
> a logical sector size of 512 bytes, will ZFS try to use blocksizes of
> less than 4KB ? Blocksize in ZFS seems to be dynamic (at least when
> not told to use a fixed blocksize), but I didn't see somewhere in the
> manpage or Sun's website which minimum blocksize ZFS would use for
> small files, and if there is a lower limit on blocksizes to use.
>
> >
> >
> > 2010/3/17 Mohacsi Janos <moh...@niif.hu>
> >
> >>
> >>
> >>
> >> On Wed, 17 Mar 2010, Dag-Erling Sm?rgrav wrote:
> >>
> >> Mohacsi Janos <moh...@niif.hu> writes:
> >>>
> >>>> What is the situation with ATA 4K dirves in FreeBSD? Are there
> >>>> any support for them in fdisk or disklabel?
> >>>>
> >>>
> >>> Hmm, didn't we discuss this already? All we need to do is change the
> >>> defaults in fdisk so it rounds partition offsets and sizes to a
> multiple
> >>> of 8 sectors (or 16 for future-proofing) instead of aligning them with
> >>> fictitious cylinder boundaries. Bsdlabel, as disklabel is properly
> >>> known, already DTRT: by default, the first partition starts at offset
> >>> 16. Just make sure you specify sizes that are divisible by 8 or 16
> >>> blocks (not an issue if you use the M or G suffixes). Sysinstall
> >>> operates in megabytes.
> >>>
> >>
> >> Thanks for the information.
> >>
> >>
> >> _______________________________________________
> >> freebsd...@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >> To unsubscribe, send any mail to "
> freebsd-hacke...@freebsd.org"
> >>
> > _______________________________________________
> > freebsd...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "
> freebsd-hacke...@freebsd.org"
> >
>
>
>
> --
> Olivier Smedts _
> ASCII ribbon campaign ( )
> e-mail: oli...@gid0.org - against HTML email & vCards X
> www: http://www.gid0.org - against proprietary attachments / \
>
> "Il y a seulement 10 sortes de gens dans le monde :
> ceux qui comprennent le binaire,
> et ceux qui ne le comprennent pas."
>


------------------------------

Message: 12
Date: Wed, 17 Mar 2010 18:23:26 +0000
From: Bruce Cran <br...@cran.org.uk>
Subject: Re: ATA 4K sector issues
To: Olivier Smedts <oli...@gid0.org>
Cc: freebsd...@freebsd.org, Mohacsi Janos <moh...@niif.hu>
Message-ID: <201003171823...@cran.org.uk>
Content-Type: Text/Plain; charset="iso-8859-1"

On Wednesday 17 March 2010 18:16:09 Olivier Smedts wrote:

> Why not on geom_md ?

Thanks! After getting a "no such geom" message when I tried a couple of
commands without having created any partitions I presumed it was looking for a
DISK provider.

--
Bruce Cran


------------------------------

Message: 13
Date: Wed, 17 Mar 2010 19:28:18 +0100
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: ATA 4K sector issues
To: Thiago Damas <tda...@gmail.com>
Cc: Olivier Smedts <oli...@gid0.org>, freebsd...@freebsd.org,
Mohacsi Janos <moh...@niif.hu>
Message-ID: <864oke6...@ds4.des.no>
Content-Type: text/plain; charset=utf-8

Thiago Damas <tda...@gmail.com> writes:
> With UFS, I previouly did some tests (in portuguese):

Some commentary would be nice.

DES
--
Dag-Erling Smørgrav - d...@des.no


------------------------------

Message: 14
Date: Wed, 17 Mar 2010 15:37:33 -0300
From: Thiago Damas <tda...@gmail.com>
Subject: Re: ATA 4K sector issues
To: Dag-Erling Sm?rgrav <d...@des.no>
Cc: Olivier Smedts <oli...@gid0.org>, freebsd...@freebsd.org,
Mohacsi Janos <moh...@niif.hu>
Message-ID:
<f8e3d83f1003171137t1b9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

With UFS, I previouly did some tests (in portuguese):

Partition without begin aligned:
=> 34 1953525101 ad4 GPT (932G)
34 1953525101 1 freebsd-ufs (932G)

newfs -U (default -f 2048 -b 16384)

# time tar xfj
/install/releases/i386/8.0-RELEASE/8.0-RELEASE/ports/ports.tgz
2.342u 5.013s 20:35.65 0.5% 64+1091k 6623+2734io 0pf+0w

newfs -U -f 4096 -b 32768
# time tar xfj
/install/releases/i386/8.0-RELEASE/8.0-RELEASE/ports/ports.tgz

2.590u 5.263s 22:06.32 0.5% 63+1087k 10911+1676io 0pf+0w


Partition aligned on 4k boundaries
=> 34 1953525101 ad4 GPT (932G)
34 30 - free - (15K)
64 1953525071 1 freebsd-ufs (932G)

newfs -U (default -f 2048 -b 16384)
# time tar xfj
/install/releases/i386/8.0-RELEASE/8.0-RELEASE/ports/ports.tgz
2.392u 5.000s 10:24.15 1.1% 64+1095k 8375+2735io 0pf+0w

newfs -U -f 4096 -b 32768

# time tar xfj
/install/releases/i386/8.0-RELEASE/8.0-RELEASE/ports/ports.tgz
2.547u 5.567s 1:25.50 9.4% 64+1088k 11880+1755io 0pf+0w


Aligning the partition, and ajusting the block/fragment size, I went
from 22minutes to 1m25s.

But, I tried every combination possible with ZFS, and always get
slow performance (something like 2, 3 MB/s write speed)

2010/3/17 Dag-Erling Smørgrav <d...@des.no>

> Thiago Damas <tda...@gmail.com> writes:
> > With UFS, I previouly did some tests (in portuguese):
>
> Some commentary would be nice.
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no
>


------------------------------

Message: 15
Date: Wed, 17 Mar 2010 21:04:03 +0200
From: Alex RAY <r...@ddteam.net>
Subject: GPIO button and userspace
To: hac...@freebsd.org
Message-ID:
<c47304e21003171204j705...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hackers
help find the correct answer, in what way I can send interrupt on GPIO to
the userspace script.
I know that I can make the device, and open it in program, but it is
cumbersome.
I know what I can run the script from the kernel, as in Linux, but I think
this is not the right way?

--
WBW
-------
Rybalko Aleksandr r...@dlink.ua
aka Alex RAY r...@ddteam.net


------------------------------

Message: 16
Date: Wed, 17 Mar 2010 12:14:49 -0700
From: Oleksandr Tymoshenko <go...@bluezbox.com>
Subject: Re: GPIO button and userspace
To: Alex RAY <r...@ddteam.net>
Cc: hac...@freebsd.org
Message-ID: <A4CCE92C-CDDD-4EB8...@bluezbox.com>
Content-Type: text/plain; charset=us-ascii


On 2010-03-17, at 12:04 PM, Alex RAY wrote:

> Hackers
> help find the correct answer, in what way I can send interrupt on GPIO to
> the userspace script.
> I know that I can make the device, and open it in program, but it is
> cumbersome.
> I know what I can run the script from the kernel, as in Linux, but I think
> this is not the right way?

IMHO the best way to implement it is to run scripts through devd. e.g. create
use subsystem "GPIO" and few event types: "BUTTON_DOWN", "BUTTON_UP",
/add yours here/. From the kernel side it's just a matter of calling devctl_notify if I got it right.

--
gonzo

------------------------------

Message: 17
Date: Wed, 17 Mar 2010 13:23:23 -0700 (PDT)
From: Matthew Dillon <dil...@apollo.backplane.com>
Subject: Re: ATA 4K sector issues
To: freebsd...@freebsd.org
Message-ID: <201003172023....@apollo.backplane.com>

We experimented a bit with aligning fdisk (dos slices) by changing
the sector offset to 2 but I came to the conclusion that it was better
to do the alignment in disklabel / gpt / whatever higher-level
partitioner floats your boat and not mess with anything the BIOS
uses to boot the machine

My recommendation is to use a 1MB physical base alignment. That's what
I adjusted DragonFly's disklabel64 to do. It's definitely best to
have the partitioner deal with it instead of having to mess around
manually because the partitioner can calculate the actual physical
alignment by querying the kernel's disk subsystem regardless of the
topology.

There are several reasons for using a large alignment:

* A variety of media already uses much larger physical block sizes.
MLC flash uses 128K and SLC uses 64K blocks. See the note below
on why this matters even though SSDs do write combining.

* A larger alignment is more likely to work well as a default in
RAID configurations and doesn't hurt non-RAID.

* The kernel cluster I/O subsystem wants to collect stuff into 64K-256K
clusters for reading and writing (writing being the most important).
A larger alignment plus some minor tweeks in the cluster code will
cause the cluster writes to also be well aligned.

* Even though UFS does not take advantage of cluster alignment
(because BMAP tends to align only to the UFS block size which
is a fairly small <= 32K usually), filesystems such as ZFS (with
128K blocks I believe) and HAMMER (with 64K blocks and 8MB super
blocks) will. And fixing up UFS isn't difficult. One might need
to mess with the cylinder group alignment and make some minor tweeks
to the bmap allocator but that's about it.

* A large alignment hurts nothing. Who cares about ~512K-1MB of wasted
space at the beginning of the drive? I don't.

This is particularly important for SSDs. Even though SSDs do write
combining a properly aligned write will theoretically greatly improve
write endurance by reducing internal fragmentation, reducing write
amplification effects, and also reducing the amount of internal
rewriting the drive does to defragment and wear-level. It is hard
to test this but I am seeing wear rates condusive with a 100TB write
endurance on 40G Intel drives vendor-speced for a 35TB write endurance.

So even though you might not see a major difference in performance
you could very well see a big difference in write endurance. It isn't
possible to benchmark this with a standard benchmark which keeps the
SSD 100% active so I've been using real work loads and it just takes
forever to tick-down the SSDs wear-meter. The SSD also needs idle
time to implement internal defragmentation and wear leveling efficiently
(This seems more apparent in the OCZs than in the Intels).

There are a lot of moving parts in the kernel related to alignment.
The cluster code and the filesystem block allocation code are the two
biggest issues and adjustments have to made to take proper advantage
of it, particularly for SSDs.

So the answer is: Aligning things certainly isn't going to hurt
anything so you might as well kick it hard (use a large alignment)
so you don't have to revisist the problem again a year from now.

--

For hard drives with larger physical sector sizes it shouldn't matter
for asynchronous writes. It really shouldn't. And nearly all of UFS's
writes are asynchronous. That said:

I read Thiago's posting. I will note something specifics about a ports
tarball. Ports has 261,000+ files in it, mostly small. UFS and the
cluster code CANNOT COMBINE those writes (because the buffer-cache for
file data is per-vnode), so UFS will wind up doing a very large number
of fragment-sized writes.

These fragment-sized writes (4K in Thiago's aligned test that ran in
1:25, and 2K in Thiago's aligned test that ran in 10:24) should STILL
be write-combined in the drive. That is, UFS STILL has good write
linearity even with the small writes.

So I suspect the issue here is that the drive is not properly
write-combining the writes, possibly coupled with additional issues
in UFS's bmap and inode allocator that might not be presenting the
drive with enough write-combinable data that fits in the drive's cache,
forcing the drive to do a lot of read-before-write.

In terms of write-combinable data and UFS it could be a cylinder-group
alignment issue. Bitmap blocks are a particular problem because they
use an odd-sized block size (typically 6K if I remember right), though
I'm not sure how the filesystem fragment size effects it.

You would have to instrument the write activity to determine how
good the linearity is verses the size of the drive's ram cache.
There are definitely several possible explanations for the horrible
performance when using 2K fragments.

ZFS (and also HAMMER) would not have this particular problem. ZFS
clearly has other issues in those tests but I don't know enough about
its internals to guess, other than maybe it is a ZIL tuning issue.

-Matt

------------------------------

Message: 18
Date: Wed, 17 Mar 2010 23:05:41 +0200
From: Alex RAY <r...@ddteam.net>
Subject: Re: GPIO button and userspace
To: Oleksandr Tymoshenko <go...@bluezbox.com>
Cc: hac...@freebsd.org
Message-ID: <2010031723054...@ddteam.net>
Content-Type: text/plain; charset=US-ASCII

On Wed, 17 Mar 2010 12:14:49 -0700
Oleksandr Tymoshenko <go...@bluezbox.com> wrote:

>
> On 2010-03-17, at 12:04 PM, Alex RAY wrote:
>
> > Hackers
> > help find the correct answer, in what way I can send interrupt on GPIO to
> > the userspace script.
> > I know that I can make the device, and open it in program, but it is
> > cumbersome.
> > I know what I can run the script from the kernel, as in Linux, but I think
> > this is not the right way?
>
> IMHO the best way to implement it is to run scripts through devd. e.g. create
> use subsystem "GPIO" and few event types: "BUTTON_DOWN", "BUTTON_UP",
> /add yours here/. From the kernel side it's just a matter of calling devctl_notify if I got it right.
>
> --
> gonzo
>
>
>

Sorry, I forgot to clarify that no devd here and no free space for it :)
Embedded, Flash 4M for all.

--
Alex RAY <r...@ddteam.net>


------------------------------

Message: 19
Date: Wed, 17 Mar 2010 14:11:18 -0700 (PDT)
From: Matthew Dillon <dil...@apollo.backplane.com>
Subject: Re: ATA 4K sector issues
To: freebsd...@freebsd.org
Message-ID: <201003172111....@apollo.backplane.com>

I'll note one last thing with regards to write combining within the
drive's zone cache. Drive zone caches work very well for combing
adjacent sectors when the write zones are perfectly linear (when
the writes within each zone being tracked are perfectly linear).
But the drive zone caches I've tested tend to break down very
quickly when the data is written out of order, even if all the data winds
up being present (could be combined into a linear result).

I posted a program a while back that showed that. Basically writing
512-byte sectors ordered 0, 1, 2, 3, 4, ... is very fast, but the
moment you start writing out of order, e.g. 3, 2, 1, 0, 7, 6, 5, 4,
things start to break down very quickly.

I would suspect the issue with UFS and a 2K fragment size on a 4K
physical sector drive is precisely this. When UFS mixes fragmented
writes with full block writes (related to different files), they
tend to have locality of reference but they also tend to be NOT
perfectly linear. 2K+ gaps will be created during the unpack and
filled later on, but the drive cache can't handle it.

Having lots of directories with a few small files in each probably
doesn't help matters any either but that can't be 'fixed' without
messing up UFS's ability to maintain a relatively unfragmented
filesystem over long periods of time.

This is probably what is tripping the drive up. This implies that
you absolutely must use a 4K fragment size (32K block size) and an
aligned partition when using UFS with 4K physical sector drives.

-Matt

------------------------------

Message: 20
Date: Wed, 17 Mar 2010 18:17:04 -0300
From: Thiago Damas <tda...@gmail.com>
Subject: Re: ATA 4K sector issues
To: Matthew Dillon <dil...@apollo.backplane.com>
Cc: freebsd...@freebsd.org
Message-ID:
<f8e3d83f1003171417s601...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

I'll try tomorrow more zfs tests, with 1M alignment on begining of disk.
But I also remember that zfs block size its 128k, but metadata can be of
dynamic size. And we can use compressed files too.
There is a sysctl, md_compress, that I turned out in my tests, but not
working as expected.
Why using gnop -S 4096 works well?

Thiago


------------------------------

Message: 21
Date: Wed, 17 Mar 2010 14:50:35 -0700 (PDT)
From: Matthew Dillon <dil...@apollo.backplane.com>
Subject: Re: ATA 4K sector issues
To: Thiago Damas <tda...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID: <201003172150....@apollo.backplane.com>


: There is a sysctl, md_compress, that I turned out in my tests, but not
:working as expected.
: Why using gnop -S 4096 works well?
:
:Thiago

You are setting the sector size to 4K with gnop -S 4096 so presumably
ZFS will not do any fragmented writes smaller than that. I'm not
sure why that would matter except possibly for ZIL writes. In the
case of ZIL if ZFS is using sector-sized writes (I don't know what it
actually uses) then setting the sector size to 4K would be more
efficient as the drive would not have to issue a read-before-write
when the disk cache is flushed after the ZIL write.

One important aspect of having the filesystem use a larger logical
block size, such as 4K or 16K or 32K etc, is that the filesystem
itself knows whether any trailing data is garbage or not and will
avoid doing a read-before-write when writing small amounts of data.

Most of the time if the filesystem is allocating space from its blockmap
it knows the trailing data in the block is garbage and will zero it
instead of performing a read-before-write. Also, the buffer cache covers
hundreds of megabytes verses the hard drive cache which is typically
only 8-64MB (though the OCZ Colosus has 128M). Still, this means the
kernel will do a much better job write-combining than the drive.

The drive has no knowledge of what is garbage and what is not at the
drive level, so the moment this stuff moves out of the drive and into
the kernel you reap rewards on these larger physical sector-sized drives.

-Matt

------------------------------

Message: 22
Date: Wed, 17 Mar 2010 14:27:02 -0700
From: Steve Franks <bahama...@gmail.com>
Subject: Re: flash drive crashes hald on amd64
To: george+...@m5p.com
Cc: freebsd...@freebsd.org
Message-ID:
<539c60b91003171427o1e8...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Right there with you on this one. My solution was to get rid of hal :)

Steve


------------------------------

Message: 23
Date: Wed, 17 Mar 2010 23:31:12 +0200
From: Andrew Stesin <ste...@gmail.com>
Subject: Re: ATA 4K sector issues
To: Matthew Dillon <dil...@apollo.backplane.com>
Cc: freebsd...@freebsd.org
Message-ID:
<28a799251003171431o1c0...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

2010/3/17 Matthew Dillon <dil...@apollo.backplane.com>:
>    you absolutely must use a 4K fragment size (32K block size) and an
>    aligned partition when using UFS with 4K physical sector drives.

Sorry for my ignorance, but what's wrong with making this the default
setting for newfs regardless of whatever the drive is?

Thanks,
Andrew


------------------------------

Message: 24
Date: Wed, 17 Mar 2010 20:23:10 -0300
From: Thiago Damas <tda...@gmail.com>
Subject: Re: ATA 4K sector issues
To: Andrew Stesin <ste...@gmail.com>, Matthew Dillon
<dil...@apollo.backplane.com>, freebsd...@freebsd.org
Message-ID:
<f8e3d83f1003171623s1ac...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Waste of disk space. With 2K frag size, a file of 1k will use a
minimum of 2K, wasting 1k. With 4k frag size it will waste 3k.

2010/3/17, Andrew Stesin <ste...@gmail.com>:
> 2010/3/17 Matthew Dillon <dil...@apollo.backplane.com>:
>>    you absolutely must use a 4K fragment size (32K block size) and an
>>    aligned partition when using UFS with 4K physical sector drives.
>
> Sorry for my ignorance, but what's wrong with making this the default
> setting for newfs regardless of whatever the drive is?
>
> Thanks,
> Andrew
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>


------------------------------

Message: 25
Date: Wed, 17 Mar 2010 18:24:49 -0700
From: Garrett Cooper <yane...@gmail.com>
Subject: Re: flash drive crashes hald on amd64
To: Steve Franks <bahama...@gmail.com>
Cc: freebsd...@freebsd.org, george+...@m5p.com
Message-ID:
<7d6fde3d1003171824q6a...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Mar 17, 2010 at 2:27 PM, Steve Franks <bahama...@gmail.com> wrote:
> Right there with you on this one.  My solution was to get rid of hal :)

1. ports@ or x11@ may be a better place to discuss this.
2. If you compiled hal port with debug, then the corefile will be
useful; otherwise it's useless. If you haven't compiled with debug, do
make -C /usr/ports/*/hal -DDEBUG clean deinstall install
3. find / -name '*.core' will help you find the corefile.

Cheers,
-Garrett


------------------------------

Message: 26
Date: Thu, 18 Mar 2010 10:54:14 +0100
From: Samuel Mart?n Moro <fau...@gmail.com>
Subject: ntfsprogs
To: po...@freebsd.org, freebsd...@freebsd.org
Message-ID:
<ce5f79aa1003180254w537...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi.

I made two patches for ntfsprogs.
(and btw, I don't know: who's the port mainter? who should I give these
patches?)

The first one, in libntfs/device.c, adding the correct defines, to get the
device geometry.
The second one, in ntfsprogs/mkntfs.c, managing character (previously
block)devices.

Also, the second patch correct an infinite loop, when linking to libublio
(and/or its 'bad' use in ntfsprogs):

Indeed, using UBLIO_BLOCK_SIZE 262144 may work while working on the entire
device.
But while working on parts, it may be better to use sector_per_track *
sector_size (or something like that...).
Otherwise, ublio try to read after the end of the drive.


With these patches, mkntfs is correctly working without ublio.
And it quite works with ublio (ask for a chkdsk under windows to make the
end boot, only if partitionning disk, but I guess one can run
UBLIO_BLOCK_SIZE=`expr 63 '*' 255` mkntfs $dev to avoid troubles).

there's still an other problem I did'nt fix yet:
a chkdsk under windows, after formatting with mkntfs, says there's a bad
$UpCase file.
Indeed, a few differences between the two versions...
I'll post the next patch when I'll have time to work on it.

Samuel Martín Moro
{EPITECH.} tek4
CamTrace S.A.S
sorry for my english...

------------------------------

Message: 27
Date: Thu, 18 Mar 2010 15:25:17 +0530
From: "Anupam Sharma - ERS, HCL Tech" <Anupam...@hcl.in>
Subject: FreeBSD pxeboot installation from redhat
To: "freebsd...@freebsd.org" <freebsd...@freebsd.org>
Message-ID:
<F1BA52847732864FB01BB...@NDA-HCLT-EVS04.HCLT.CORP.HCL.IN>

Content-Type: text/plain; charset="us-ascii"

Hi,
I want to automate FreeBSD pxeboot installation from redhat. I need to add install.cfg file as kickstart. but I don't know how to pass is?

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------


------------------------------

Message: 28
Date: Thu, 18 Mar 2010 11:31:09 +0100
From: Gary Jennejohn <gary.je...@freenet.de>
Subject: Re: ntfsprogs
To: Samuel Mart?n Moro <fau...@gmail.com>
Cc: po...@freebsd.org, freebsd...@freebsd.org
Message-ID: <20100318113...@ernst.jennejohn.org>
Content-Type: text/plain; charset=US-ASCII

On Thu, 18 Mar 2010 10:54:14 +0100
Samuel Mart__n Moro <fau...@gmail.com> wrote:

> I made two patches for ntfsprogs.
> (and btw, I don't know: who's the port mainter? who should I give these
> patches?)
>

There isn't a maintainer. The best thing is to file a PR with your
patches attached so they won't get lost in the noise.

---
Gary Jennejohn


------------------------------

Message: 29
Date: Thu, 18 Mar 2010 12:09:21 +0100
From: Samuel Mart?n Moro <fau...@gmail.com>
Subject: Re: ntfsprogs
To: gary.je...@freenet.de
Cc: po...@freebsd.org, freebsd...@freebsd.org
Message-ID:
<ce5f79aa1003180409p5a...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

done
thanks

Samuel Martín Moro
{EPITECH.} tek4
CamTrace S.A.S


On Thu, Mar 18, 2010 at 11:31 AM, Gary Jennejohn
<gary.je...@freenet.de>wrote:

> On Thu, 18 Mar 2010 10:54:14 +0100
> Samuel Mart__n Moro <fau...@gmail.com> wrote:
>
> > I made two patches for ntfsprogs.
> > (and btw, I don't know: who's the port mainter? who should I give these
> > patches?)
> >
>
> There isn't a maintainer. The best thing is to file a PR with your
> patches attached so they won't get lost in the noise.
>
> ---
> Gary Jennejohn
>


------------------------------


End of freebsd-hackers Digest, Vol 364, Issue 4
***********************************************

0 new messages