Re: Poor interactive performance with I/O loads with fsync()ing
On Sun, 11 Apr 2010 18:03:00 +0300, Avi Kivity a...@redhat.com wrote: On 04/09/2010 05:56 PM, Ben Gamari wrote: On Mon, 29 Mar 2010 00:08:58 +0200, Andi Kleena...@firstfloor.org wrote: Ben Gamaribgamari.f...@gmail.com writes: ext4/XFS/JFS/btrfs should be better in this regard I am using btrfs, so yes, I was expecting things to be better. Unfortunately, the improvement seems to be non-existent under high IO/fsync load. btrfs is known to perform poorly under fsync. Has the reason for this been identified? Judging from the nature of metadata loads, it would seem that it should be substantially easier to implement fsync() efficiently. - Ben -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor interactive performance with I/O loads with fsync()ing
Has the reason for this been identified? Judging from the nature of metadata loads, it would seem that it should be substantially easier to implement fsync() efficiently. By design a copy on write tree fs would need to flush a whole tree hierarchy on a sync. btrfs avoids this by using a special log for fsync, but that causes more overhead if you have that log on the same disk. So IO subsystem will do more work. It's a bit like JBD data journaling. However it should not have the stalls inherent in ext3's journaling. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't mount removable device if device name changes.
Hi, What is your kernel version? Btrfs hols device names which construct filesystems and updating device name(device renaming) is merged just in last month. Regards, taruisi (2010/04/11 10:49), cwillu wrote: I've got a btrfs on an sd card, which I'm using as the root fs on a beagle. That's not the problem :) The machine I generate my images on has an internal sd reader, and I also have a usb card reader. After creating the fs on the internal reader, I ended up plugging it in on the external reader. internal: sdd external: sdh mount /dev/sdh2 /mnt -t btrfs mount: /dev/sdh2: can't read superblock [15035.538462] device fsid 48fadf7ed76537-bb9c7266ecb8b2 devid transid 8986 /dev/sdh2 [15035.538462] open /dev/sdd2 failed If I plug it back into the internal reader, it mounts fine on /dev/sdd2. An strace of btrfsctl -a shows it reading /dev/sdh2, and there's no mention of /dev/sdd: open(/dev/sdh2, O_RDONLY) = 4 pread(4, \2067kF\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 2859, 65536) = 2859 The fs mounts fine on the external reader on a different machine. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- taruisi -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
