On Nov 18, 2013, at 1:30 AM, Gene Czarcinski <gene(a)czarc.net> wrote:
On 11/17/2013 03:23 PM, Chris Murphy wrote:
> So I'm trying to preallocate a VM image file using dd and I'm getting a weird
hang regardless of file system (XFS and Btrfs so far). Existing shells, local and ssh, are
very sluggish but work. I can't create new shells, either local or ssh, they time out.
This is the command I'm using:
>
> dd if=/dev/zero of=fedoraA.img bs=1M count=40000
Two questions here:
1. Have you tried bs=1K count=40000000 to see if it makes a difference?
Still happens. Takes longer to happen, but that's probably because 1K is simply a lot
less efficient and doesn't.
2. What does filefrag show when you are done (especially on btrfs)?
For a 20G it was I think 33 extents for btrfs and 2 for XFS.
I do assume that on btrfs you are doing "the right thing"
and setting chattr +C for the directory.
Yes.
OK, now some addition info … what is the hardware/software?
Fedora 20 with current updates except kernel is at 3.11.7-300. Hardware is a Macbook Pro
4,1 with a WDC Scorpio Blue in it.
I would try playing with the file size and the block size to see what difference it makes
(if any). Right now, I (for one) cannot duplicate your problem.
Would stracing the ls -lsh indicate where the hang is occurring? I wonder if this is a NCQ
problem and the drive is just literally tied up with a ton of write requests and the
scheduler isn't being smart or fast enough to reorder the likely dozen or two commands
needed to execute a "simple" ls. Instead the commands shuffled among a pile of
write commands.
I've only tested cqf (the default) although maybe deadline would give better results
with this particular use case. It just seems weird to essentially hang the system for
something that takes only 6% CPU. Maybe I'll try adding a 2nd drive for the dd
operation, leaving the primary drive / rootfs to complete my other requests and see if
this is a disk contention problem.
One other little thing, are you getting any disk errors? Did you try
running gnome-disks and look at the SMART data?
No disk errors.
Chris Murphy