On 05/26/2010 10:12 AM, Les Mikesell wrote:
> On 5/26/2010 9:52 AM, John R Pierce wrote:
>>
Is that one of those WD drives that falsely
reports its physical sector size as 512 bytes?
>>>
>>>From the Scorpio blue specs, if I divide the capacity by the number of
>>> sectors, I get
Les Mikesell wrote:
> On 5/26/2010 9:52 AM, John R Pierce wrote:
>
Is that one of those WD drives that falsely
reports its physical sector size as 512 bytes?
>>> From the Scorpio blue specs, if I divide the capacity by the number of
>>> sectors, I get 512...
>>>
>>
On 5/26/2010 9:52 AM, John R Pierce wrote:
>
>>> Is that one of those WD drives that falsely
>>> reports its physical sector size as 512 bytes?
>>>
>>
>> From the Scorpio blue specs, if I divide the capacity by the number of
>> sectors, I get 512...
>>
>
>
>
> all these new 'advanced' drives look
John Doe wrote:
> From: Robert Nichols
>
>> Is that one of those WD drives that falsely
>> reports its physical sector size as 512 bytes?
>>
>
> From the Scorpio blue specs, if I divide the capacity by the number of
> sectors, I get 512...
>
all these new 'advanced' drives look to
John Doe wrote:
> From: Robert Nichols
>> Is that one of those WD drives that falsely
>> reports its physical sector size as 512 bytes?
>
>>From the Scorpio blue specs, if I divide the capacity by the number of
>>sectors, I get 512...
>
So is there any way to tell the kernel to write 4k at on
From: Robert Nichols
> Is that one of those WD drives that falsely
> reports its physical sector size as 512 bytes?
>From the Scorpio blue specs, if I divide the capacity by the number of
>sectors, I get 512...
JD
___
CentOS mailing list
Cen
On 05/24/2010 12:41 PM, Les Mikesell wrote:
> On 5/24/2010 6:56 AM, Robert Nichols wrote:
>>
>>>
>>> The trayless internal hotswap enclosures claim to be good for 10,000+
>>> insertions
>>> and I'm using larger ones for the desktop drives I had been using without
>>> any
>>> problems. I have se
On 5/24/2010 6:56 AM, Robert Nichols wrote:
>
>>
>> The trayless internal hotswap enclosures claim to be good for 10,000+
>> insertions
>> and I'm using larger ones for the desktop drives I had been using without any
>> problems. I have seen some postings to the effect that I need a newer
>> ke
On 05/23/2010 01:57 PM, Les Mikesell wrote:
> Robert Nichols wrote:
>> Another thing to keep in mind is that the SATA spec. only requires the
>> internal SATA connector to withstand 50 insertions. I picked up some
>> nice acomdata (TM) eSATA housings for the drives (512-byte sectors,
>> thankfully
Robert Nichols wrote:
> On 05/22/2010 08:40 PM, Les Mikesell wrote:
>> Robert Nichols wrote:
>>> On 05/22/2010 07:39 PM, Robert Nichols wrote:
>>> I should add that the kernel normally will do I/O in multiples of its 4KB
>>> (typical) page size where possible, but I have no idea whether any effort
On 05/22/2010 08:40 PM, Les Mikesell wrote:
> Robert Nichols wrote:
>> On 05/22/2010 07:39 PM, Robert Nichols wrote:
>> I should add that the kernel normally will do I/O in multiples of its 4KB
>> (typical) page size where possible, but I have no idea whether any effort
>> is made to align those wr
Robert Nichols wrote:
> On 05/22/2010 07:39 PM, Robert Nichols wrote:
>> On 05/22/2010 05:46 PM, Les Mikesell wrote:
>>> Does the 4K sector size mean that the drive is going to read the 4K chunk
>>> then
>>> merge in the 512 bytes you wrote, the wait for the sector come around again
>>> to
>>> wr
On 05/22/2010 07:39 PM, Robert Nichols wrote:
> On 05/22/2010 05:46 PM, Les Mikesell wrote:
>> Does the 4K sector size mean that the drive is going to read the 4K chunk
>> then
>> merge in the 512 bytes you wrote, the wait for the sector come around again
>> to
>> write it back? I guess that cou
On 05/22/2010 05:46 PM, Les Mikesell wrote:
> Les Mikesell wrote:
>> Robert Nichols wrote:
>>> On 05/22/2010 11:29 AM, Les Mikesell wrote:
Robert Nichols wrote:
> On 05/21/2010 07:39 PM, Robert Nichols wrote:
>> You have another way out. By my calculation, that drive is partitioned
>>
Les Mikesell wrote:
> Robert Nichols wrote:
>> On 05/22/2010 11:29 AM, Les Mikesell wrote:
>>> Robert Nichols wrote:
On 05/21/2010 07:39 PM, Robert Nichols wrote:
> You have another way out. By my calculation, that drive is partitioned
> in DOS compatibility mode, which leaves the rem
Robert Nichols wrote:
> On 05/22/2010 11:29 AM, Les Mikesell wrote:
>> Robert Nichols wrote:
>>> On 05/21/2010 07:39 PM, Robert Nichols wrote:
You have another way out. By my calculation, that drive is partitioned
in DOS compatibility mode, which leaves the remainder of the MBR track
>>>
On 05/22/2010 11:29 AM, Les Mikesell wrote:
> Robert Nichols wrote:
>> On 05/21/2010 07:39 PM, Robert Nichols wrote:
>>> You have another way out. By my calculation, that drive is partitioned
>>> in DOS compatibility mode, which leaves the remainder of the MBR track
>>> unused. Running fdisk in e
Robert Nichols wrote:
> On 05/21/2010 07:39 PM, Robert Nichols wrote:
>> You have another way out. By my calculation, that drive is partitioned
>> in DOS compatibility mode, which leaves the remainder of the MBR track
>> unused. Running fdisk in expert mode ("x" command), you can move the
>> part
On 05/21/2010 07:39 PM, Robert Nichols wrote:
> You have another way out. By my calculation, that drive is partitioned
> in DOS compatibility mode, which leaves the remainder of the MBR track
> unused. Running fdisk in expert mode ("x" command), you can move the
> partition's beginning of data ("
On 05/21/2010 04:32 PM, Les Mikesell wrote:
> On 5/21/2010 4:19 PM, John R Pierce wrote:
>> Les Mikesell wrote:
>>> But it is just a match for the Seagate drives with the default layout
>>> using one partition that fills the disk. If I have to skip some amount
>>> at the start of the partition I t
On 5/21/2010 5:46 PM, John R Pierce wrote:
> Les Mikesell wrote:
>> These is a backuppc archive with millions of hardlinks that will take
>> forever to copy if I have to do a file-oriented copy onto a different
>> partition size.
>>
>
> have you tried a dump | restore style Ext{3|2}FS replica? th
Les Mikesell wrote:
> These is a backuppc archive with millions of hardlinks that will take
> forever to copy if I have to do a file-oriented copy onto a different
> partition size.
>
have you tried a dump | restore style Ext{3|2}FS replica? that works
by inode and does it pretty efficient
On 5/21/2010 4:37 PM, Benjamin Franz wrote:
> On 05/21/2010 02:32 PM, Les Mikesell wrote:
> [..]
>> Disk /dev/sdh: 750.1 GB, 750156374016 bytes
>> 255 heads, 63 sectors/track, 91201 cylinders
>> Units = cylinders of 16065 * 512 = 8225280 bytes
>>
>> Device Boot Start End Blocks Id
On 05/21/2010 02:32 PM, Les Mikesell wrote:
[..]
> Disk /dev/sdh: 750.1 GB, 750156374016 bytes
> 255 heads, 63 sectors/track, 91201 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sdh1 1 91201 732572001 f
On 5/21/2010 4:19 PM, John R Pierce wrote:
> Les Mikesell wrote:
>> But it is just a match for the Seagate drives with the default layout
>> using one partition that fills the disk. If I have to skip some amount
>> at the start of the partition I think that will make the partition size
>> not matc
Les Mikesell wrote:
> But it is just a match for the Seagate drives with the default layout
> using one partition that fills the disk. If I have to skip some amount
> at the start of the partition I think that will make the partition size
> not match, making it impossible to add as a raid membe
On 5/21/2010 12:13 PM, John R Pierce wrote:
> Les Mikesell wrote:
>> OK, I can get a full-size Seagate 750G to resync at about 40M/s which
>> easily completes in a workday. But now what I really want to do is use
>> a laptop size 'WD Scorpio blue' drive which claims to have the same
>> sector coun
Les Mikesell wrote:
> OK, I can get a full-size Seagate 750G to resync at about 40M/s which
> easily completes in a workday. But now what I really want to do is use
> a laptop size 'WD Scorpio blue' drive which claims to have the same
> sector count but will only sync at about a tenth of the sp
On 5/13/2010 1:42 PM, Eero Volotinen wrote:
> 2010/5/13 Les Mikesell:
>> Has anything changed in updates that would affect md raid1 resync speed?
>> I regularly swap a 750G drive and resync to keep an offsite copy and
>> haven't paid enough attention to known when things changed but it seems
>> t
On Thu, 13 May 2010, Eero Volotinen wrote:
> well, try this:
>
> http://www.ducea.com/2006/06/25/increase-the-speed-of-linux-software-raid-reconstruction/
Interesting link. Thanks. I'll be interested to try it out next time I
swap out a RAID disk.
--
Paul Heinlein <> heinl...@madboa.com <> htt
2010/5/13 Les Mikesell :
> Has anything changed in updates that would affect md raid1 resync speed?
> I regularly swap a 750G drive and resync to keep an offsite copy and
> haven't paid enough attention to known when things changed but it seems
> to take much longer to sync than it did months ago,
Has anything changed in updates that would affect md raid1 resync speed?
I regularly swap a 750G drive and resync to keep an offsite copy and
haven't paid enough attention to known when things changed but it seems
to take much longer to sync than it did months ago, even if I unmount
the parti
32 matches
Mail list logo
