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
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: Poor interactive performance with I/O loads with fsync()ing
On Sun, 11 Apr 2010 18:03:00 +0300, Avi Kivity wrote: > On 04/09/2010 05:56 PM, Ben Gamari wrote: > > On Mon, 29 Mar 2010 00:08:58 +0200, Andi Kleen wrote: > > > >> Ben Gamari 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
