Prev: Hanukkah Menorah by Tzuki | Judaica Jewish Gifts
Next: more than 1 filesystem in a ntfs-partition?
From: Rahul on 2 Mar 2010 14:45
Stan Bischof <stan(a)newserve.worldbadminton.com> wrote in news:4b8d4cd1$0
$1662$742ec2ed(a)news.sonic.net:

> Are you sure you mean server _2008_ and not _2003_?
> 2003 is XP-vintage so has issue but 2008 is Vista-vintage
> and should not have a problem.

Yes, I am using "2008". It seems to be super slow still (max 10 MB/sec
writes). You are correct, from all the discussions it does seem that 2008
*should not* in theory have a problem. But I cannot explain these horrible
write speeds. Something is wrong. Maybe my settings. [There's an
"allocation unit size"; not sure if this means block size or sector size
etc.]

Which is why I want to test it in Linux which is at least more transperent
to these issues.

--
Rahul
From: Jean-David Beyer on 4 Mar 2010 11:38
Robert Heller wrote:
> At Tue, 2 Mar 2010 16:44:54 +0000 (UTC) Rahul <nospam(a)nospam.invalid>
> wrote:
>
>> John Reiser <jreiserfl(a)comcast.net> wrote in
>> news:MOedndjz0dfrqxDW4p2dnAA(a)giganews.com:
>>
>>> All drive manufacturers have begun this shift. The physical
>>> sector size now is 4096 bytes, instead of the old 512 bytes.
>> Does that have any silver lining or not at all? Or is it just a
>> manufacturer fad?
>
> Given the higher and higher bit density, the increase in sector size
> is pretty much a given (and probably long overdue). A sector size of
> 512 was invented for 360K 5.25" *floppies*!

Actually, it was no later than the DEC PDP-11 series minicomputers.
Probably earlier.

> And this was an increase from 128 byte sectors on 128K 8" floppies!
> It is just not cost effective (in terms of head movement, timing and
> indexing tracks, disk addressing, etc.) to deal with an ginormous
> number of tiny sectors. It is not like someone is going to get a 1.5
> TByte drive and store a ginormous number of tiny little files on it.
> Many *modern* file systems are using larger block sizes in order to
> deal with larger disks (e[23]fs defaults to a 4096 block size, and so
> fits right in with a 4096 physical sector size).
>
I liked the disk controller on the Computer Control DDP-224 computer.
You could change the sector size for each track on the drive. Normally,
you would not do that. Back in those days, drives held about 40
MegaBytes and that was a big deal. What I did was pick one sector size
for binary card images, another for print-line images, and a third for
moving picture images.

I could also number the blocks anyway I wanted. I numbered the binary
card image sectors so that when the program loader requested the next
block, it would be the one just about to pass under the read head. This
speeded up the program loading by a factor of about 7, IIRC. In other
words, if there were 3 sectors on a track (actually about 15), I would
number them 0, 2, 1 instead of 0, 1, 2. I learned this trick from Fred
Grammp long ago.

On machines where there is a lot of RAM compared to the bad old days
when we had only 32768 words of RAM, sector size might as well be about
the same as the track size, since you might as well read in an entire
track at a time. But even more progress has been made in hard drive
design and now there are large buffer memories in the drives themselves,
so even if you read only a few bytes, the drive is likely to read in the
entire track and be ready for you if you are reading sequentially.

So now sector size matter only for controlling the kind of fragmentation
you are going to get.


--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 11:25:01 up 43 days, 12:45, 3 users, load average: 4.10, 4.34, 4.44
First  |  Prev  | 
Pages: 1 2 3
Prev: Hanukkah Menorah by Tzuki | Judaica Jewish Gifts
Next: more than 1 filesystem in a ntfs-partition?