On Mon, 21 Feb 2011 10:16:37 -0600, Kurt Jaeger wrote:
Hi!
> Hmm, wasn't the issues with 3T drives, that they internally use
> 4K blocks and emulate 512 and that therefore 8 block alignments
> are an performance issue ?
Hi guys,
I'd just like to jump on this train real quick since I have
Pete French wrote:
> > Why may it hurt ? How may it hurt ? Which sector is written to
> > by this 'gpart' command ?
> >
> > As far as I understand, GPT writes some stuff at the beginning
> > and the end of the harddisk.
>
> Yup, this is true.
>
> > How/why will the newfs overwrite those parts ?
>
> Why may it hurt ? How may it hurt ? Which sector is written to by
> this 'gpart' command ?
>
> As far as I understand, GPT writes some stuff at the beginning and
> the end of the harddisk.
Yup, this is true.
> How/why will the newfs overwrite those parts ?
Because you are also giving it the wh
Hi!
> > Basically, I did this:
>
> > gpart create -s gpt ad7
> > newfs /dev/ad7
>
> Wow! Don't do it. It may hurt. ;-)
Why may it hurt ? How may it hurt ? Which sector is written to by
this 'gpart' command ?
As far as I understand, GPT writes some stuff at the beginning and
the end of the hard
Hi!
On Tue, 22 Feb 2011 10:23:12 +0100 Kurt Jaeger wrote:
> Basically, I did this:
> gpart create -s gpt ad7
> newfs /dev/ad7
Wow! Don't do it. It may hurt. ;-)
Please, pay attention to gpart(8) (i.e. read the manual
carefully). One should create a specific partition and
only then create a fil
Hi!
> > # glabel status
> > Name Status Components
> > ufsid/4d62938756e96a72 N/A ad7
>
> > If I use gpart, does this somehow imply glabel ?
>
> I'm not an expert at gpart(8). But my gparted disks have geom labels for
> partitions but not for disks:
Interesting.
> Can
Hi!
On Mon, 21 Feb 2011 17:55:21 +0100 Kurt Jaeger wrote:
> > > > > Feb 17 22:15:44 vserv1 kernel: GEOM: ufsid/4d5d8faa10b63ac1: using
> > > > > the primary only -- recovery suggested.
> >
> > > Boris Samorodov wrote:
> > > > It may be the case here if you to used glabel(8) to create a label
>
Hi!
> > > > Feb 17 22:15:44 vserv1 kernel: GEOM: ufsid/4d5d8faa10b63ac1: using the
> > > > primary only -- recovery suggested.
>
> > Boris Samorodov wrote:
> > > It may be the case here if you to used glabel(8) to create a label
> > > for the whole disk.
>
> > I did not use glabel on that disk.
Hi!
On Mon, 21 Feb 2011 17:16:37 +0100 Kurt Jaeger wrote:
> > > Hmm, wasn't the issues with 3T drives, that they internally use
> > > 4K blocks and emulate 512 and that therefore 8 block alignments
> > > are an performance issue ?
> >
> > > The reason I'm asking: I encounter the problem of the l
On Thu, 17 Feb 2011 21:46:43 +0100 Kurt Jaeger wrote:
> Hmm, wasn't the issues with 3T drives, that they internally use
> 4K blocks and emulate 512 and that therefore 8 block alignments
> are an performance issue ?
> The reason I'm asking: I encounter the problem of the lost
> secondary GPT table
Hi!
> > Hmm, wasn't the issues with 3T drives, that they internally use
> > 4K blocks and emulate 512 and that therefore 8 block alignments
> > are an performance issue ?
>
> > The reason I'm asking: I encounter the problem of the lost
> > secondary GPT table:
>
> > Feb 17 22:15:44 vserv1 kernel
On Thu, Feb 17, 2011 at 07:38:19PM +0700, Edho P Arief wrote:
> UFS:
>
> >>>create GPT
> # gpart create -s gpt da0
> >>>create partition, with start position 4k-aligned
> # gpart add -t freebsd-ufs -b 1024 -l mydata da0
> >>>default newfs is good enough
> # newfs -U /dev/gpt/mydata
>
>
> correct
On Thu, 17 Feb 2011, Daniel Kalchev wrote:
DK> > > > da0: Fixed Direct Access SCSI-5 device
DK> > > > da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C)
DK> >
DK> > Thanks -- is it also possible to have something like
DK> >
DK> > da0: 2861588MB (732566646 4096 byte sectors: 255H 6
Hi!
> > According to Hitachi, this is an 512b drive.
>
> Correct. This isn't a 4k drive. Datasheet:
>
> http://www.hgst.com/internal-drives/enterprise/ultrastar/ultrastar-7k3000
Hmm, wasn't the issues with 3T drives, that they internally use
4K blocks and emulate 512 and that therefore 8 bloc
In the last episode (Feb 17), Daniel Kalchev said:
> >>> da0: Fixed Direct Access SCSI-5 device
> >>> da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C)
> >
> > Thanks -- is it also possible to have something like
> >
> > da0: 2861588MB (732566646 4096 byte sectors: 255H 63S/T 364801
On Thu, Feb 17, 2011 at 6:56 PM, Kurt Jaeger wrote:
> Hi!
>
> I have one of the new 3TB drives:
>
> da0: Fixed Direct Access SCSI-5 device
> da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C)
>
> Now as far as I understand, one can operate it with many 512byte blocks
> or one can tr
da0: Fixed Direct Access SCSI-5 device
da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C)
Thanks -- is it also possible to have something like
da0: 2861588MB (732566646 4096 byte sectors: 255H 63S/T 364801C)
According to Hitachi, this is an 512b drive.
Daniel
__
Hi!
Edho P Arief wrote:
> > I have one of the new 3TB drives:
> >
> > da0: Fixed Direct Access SCSI-5 device
> > da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C)
> >
> > Now as far as I understand, one can operate it with many 512byte blocks
> > or one can try to use the internal
18 matches
Mail list logo
