You're doing two disk writes at once. To the same physical partitions or two
different ones?
tar has a penchant for 512-byte blocks and being ass-slow.
On Wed, Sep 9, 2009 at 4:52 PM, Nicholas Clark n...@ccl4.org wrote:
OK, so how come me, with 1 process streaming data to disk over 100Mb
On Wed, Sep 09, 2009 at 04:58:50PM -0400, Jonathan J. M. Katz wrote:
You're doing two disk writes at once. To the same physical partitions or two
different ones?
Same physical partition. Yes.
I still don't get why it takes so long to recover. Unless it's because Firefox
has stacked up a
2009/9/9 Nicholas Clark n...@ccl4.org:
On Wed, Sep 09, 2009 at 04:58:50PM -0400, Jonathan J. M. Katz wrote:
tar has a penchant for 512-byte blocks and being ass-slow.
How hateful.
I suppose that's why some people pipe things like that through dd with
a different output blocksize; I'd often
On Wed, Sep 9, 2009 at 5:13 PM, Philip Newton philip.new...@gmail.comwrote:
I suppose that's why some people pipe things like that through dd with
a different output blocksize; I'd often wondered that.
Though I'm sure that comes with its very own hate.
The GNU dd that ships with Linux does
Philip Newton wrote:
2009/9/9 Nicholas Clark n...@ccl4.org:
On Wed, Sep 09, 2009 at 04:58:50PM -0400, Jonathan J. M. Katz wrote:
tar has a penchant for 512-byte blocks and being ass-slow.
How hateful.
That's the Tape ARchiver for you ...
I suppose that's why some people pipe things like
On 09/09/2009 05:01 PM, Nicholas Clark wrote:
PS I'm not sure if there is XML involved here anywhere.
Sure... because those XML config files and database-wannabe storage
files are so bloated, they take extra disk reads/writes, backing up the
queue even further.
There's always room to blame XML.
On 9 Sep 2009, at 21:52, Nicholas Clark wrote:
[...]
2 gig of RAM, less than 2 gig of swap in use, CPU at 3%, but a load
average of
SEVENTEEN
Ye gods. What is it up to?
The VFS layer is ensuring that your disks are dedicated to the Holy
Write, and anything that wants to read the disk
