Monster IDE Drives

[Roger Oberholtzer]

On Tue, 17 Feb 2004 19:50:52 -0500
Kurt Wall <kwall at kurtwerks.com> wrote:

> In a 0.8K blaze of typing glory, Michael Hipp wrote:
> > Roger Oberholtzer wrote:
> > 
> > >>By "directory fiddling", you mean disk seek time, right?
> > >
> > >
> > >Probably. But it is communication with the disk of other than actual
> > >file content. I would imagine that the disk would also seek when
> > >writing data. So
> > >it is more than that. Could in fact only be a firewire driver thing on 
> > >Linux
> > >and not the disk at all.
> > 
> > "Directory fiddling" can be really slow. Last night I was moving some 
> > stuff via a USB 1.1 pocket drive. I did 'mkdir foo'. The command prompt 
> > didn't return for a *full minute*. Thought I was gonna have a coronary. 
> > It's a VFAT volume which may explain some of it.
> 
> Holy delayed write, Batman! VFAT sucks and all that, but I've never
> heard of a simple directory creation taking a minute (unless there
> were some serious disk writes going on elsewhere on the system or 
> the drive itself was about to push up weeds.

Not a minute. What I really expect (not checked, but based on my experience
with firewire DC cameras) is going on is that the firewire deals in packets.
The sbp2 driver sets up some nice sized ones. When sending a large file the
packets are always full and the data rate is somewhat maintained. When
writing smaller files this is less the case and the transfer rate drops.
Now, when making a directory entry for a file there is probably a bit if
bi-directional transfer, each of relatively small size. But, due to the
packet size... I have not explored this because we just happen to deal in
large files. The smallest are 256K or so (compressed JPEG images). Of
course, these are created every 10 or so meters of movement (resulting in
2.5 of these per second at 55 MPH (88 KM/H). So, over a day, they add up.
For this reason, transfer rate is something we monitor. Of course, we do not
transfer the images during data collection. TG for fast SCSI disks, as the
images is just one of many data items.

And, this is on ext2/3 file systems, not just vfat. vfat has its own set of
problems with small files that I recall posting to this list a year or so
ago.

-- 
+????????????????????????????+???????????????????????????????+
? Roger Oberholtzer          ?   E-mail: roger at opq.se        ?
? OPQ Systems AB             ?      WWW: http://www.opq.se/  ?
? Erik Dahlbergsgatan 41-43  ?    Phone: Int + 46 8   314223 ?
? 115 34 Stockholm           ?   Mobile: Int + 46 733 621657 ?
? Sweden                     ?      Fax: Int + 46 8   302602 ?
+????????????????????????????+???????????????????????????????+