On Nov 18, 2013, at 1:30 AM, Gene Czarcinski <gene@xxxxxxxxx> 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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
