[Question] Btrfs on iSCSI device
Hi, I setup 2 Linux servers to share the same device through iSCSI. Then I created a btrfs on the device. Then I saw the problem that the 2 Linux servers do not see a consistent file system image. Details: -- Server 1 running kernel 2.6.32, server 2 running 3.2.1 -- Both running btrfs v0.20-rc1 -- Server 2 has device /dev/vdc, exposed as iSCSI target -- Server 1 mounts the device as /dev/sda -- Server 1 'mount /dev/sda /mnt/btrfs'; server 2 'mount /dev/vdc /mnt/btrfs', -- When server 1 'touch /mnt/btrfs/foo', server 2 doesn't see any file under /mnt/btrfs -- I created /mnt/btrfs/foo on server 2 as well; then I added some content from both server 1 and server 2 to /mnt/btrfs/foo -- After that each server sees the content it adds, but not the content from the other server -- Both server 'umount /mnt/btrfs', and mount it again -- Then both servers see /mnt/btrfs/foo with the content added from server 2 (I guess it's because server 2 created the foo file later than server 1). I did a similar test on ext4 and both servers see a consistent image of the file system. When server 1 creates a foo file server 2 immediately sees it. Is this how btrfs is supposed to work? Thanks, Zhe -- 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: [Question] Btrfs on iSCSI device
On Fri, Jun 27, 2014 at 1:15 PM, Austin S Hemmelgarn wrote: > On 2014-06-27 12:34, Goffredo Baroncelli wrote: >> Hi, >> On 06/27/2014 05:44 PM, Zhe Zhang wrote: >>> Hi, >>> >>> I setup 2 Linux servers to share the same device through iSCSI. Then I >>> created a btrfs on the device. Then I saw the problem that the 2 Linux >>> servers do not see a consistent file system image. >>> >>> Details: >>> -- Server 1 running kernel 2.6.32, server 2 running 3.2.1 >>> -- Both running btrfs v0.20-rc1 >>> -- Server 2 has device /dev/vdc, exposed as iSCSI target >>> -- Server 1 mounts the device as /dev/sda >>> -- Server 1 'mount /dev/sda /mnt/btrfs'; server 2 'mount /dev/vdc >>> /mnt/btrfs', >>> -- When server 1 'touch /mnt/btrfs/foo', server 2 doesn't see any >>> file under /mnt/btrfs >>> -- I created /mnt/btrfs/foo on server 2 as well; then I added some >>> content from both server 1 and server 2 to /mnt/btrfs/foo >>> -- After that each server sees the content it adds, but not the >>> content from the other server >>> -- Both server 'umount /mnt/btrfs', and mount it again >>> -- Then both servers see /mnt/btrfs/foo with the content added from >>> server 2 (I guess it's because server 2 created the foo file later >>> than server 1). >>> >>> I did a similar test on ext4 and both servers see a consistent image >>> of the file system. When server 1 creates a foo file server 2 >>> immediately sees it. >>> >>> Is this how btrfs is supposed to work? >> >> I don't think that it is possible to mount the _same device_ at the _same >> time_ on two different machines. And this doesn't depend by the filesystem. >> >> The fact that you see it working, I suspect that is is casual. >> >> When I tried this (same scsi HD connected to two machines), I had to ensure >> that the two machines never accessed to the HD at the same time. >> >>> >>> Thanks, >>> >>> Zhe >>> -- >>> 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 >>> >> >> > If you need shared storage like that, you need to use a real cluster > filesystem like GFS2 or OCFS2, BTRFS isn't designed for any kind of > concurrent access to shared storage from separate systems. > The reason it appears to work when using iSCSI and not with directly > connected parallel SCSI or SAS is that iSCSI doesn't provide low level > hardware access. > I did more testing with ext4 and it supports what Goffredo and Austin said above. Error message is "cannot access xxx: Input/output error". It seems to me that both servers hold some file system data structures in memory and eventually conflict with each other (like writing inode info to the same blocks). -- 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
Question about debugfs on btrfs
Hi, I'm trying to use a functionality like "debugfs blocks" or "dump_extents" on a btrfs partition. The current debugfs user space program doesn't seem to support it (from e2fsprogs). I cannot find debugfs in btrfs-progs either. Any advice on how to do it? Thanks! Zhe -- 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: Question about debugfs on btrfs
Thanks Hugo, that works great. On Wed, Jul 2, 2014 at 12:31 PM, Hugo Mills wrote: > On Wed, Jul 02, 2014 at 12:23:01PM -0400, Zhe Zhang wrote: >> Hi, >> >> I'm trying to use a functionality like "debugfs blocks" or >> "dump_extents" on a btrfs partition. The current debugfs user space >> program doesn't seem to support it (from e2fsprogs). I cannot find >> debugfs in btrfs-progs either. Any advice on how to do it? > >I don't know what the ext* debugfs does, but the odds of it > actually working on btrfs are pretty slim, given that they're > completely different filesystems. :) > >If you want a human-readable view of the filesystem's metadata, > then btrfs-debug-tree is the tool you need. > >Hugo. > > -- > === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === > PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk >--- Someone's been throwing dead sheep down my Fun Well --- -- 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
[Question] disk_bytenr with multiple devices
When a btrfs has multiple devices (e.g. /dev/sdb, /dev/sdc), how should I interpret disk_bytenr in btrfs_file_extent_item? Does it depend on the striping config? Say I used raid0, then disk_bytenr 0~64K will be on /dev/sdb, and 64K~128K on /dev/sdc? Thanks, Zhe -- 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: [Question] disk_bytenr with multiple devices
Thanks Qu. I followed the wiki and your advice and finally got it working. BTW I created a program printing the disk block addresses of a file. URL here if anyone else finds it a useful feature: https://github.com/oldcap/btrfs-progs/blob/master/btrfs-file-blocks.c On Fri, Jul 11, 2014 at 1:23 AM, Qu Wenruo wrote: > > Original Message > Subject: [Question] disk_bytenr with multiple devices > From: Zhe Zhang > To: linux-btrfs@vger.kernel.org > Date: 2014年07月11日 02:21 >> >> When a btrfs has multiple devices (e.g. /dev/sdb, /dev/sdc), how >> should I interpret disk_bytenr in btrfs_file_extent_item? >> >> Does it depend on the striping config? Say I used raid0, then >> disk_bytenr 0~64K will be on /dev/sdb, and 64K~128K on /dev/sdc? >> >> Thanks, >> Zhe >> -- >> 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 > > https://btrfs.wiki.kernel.org/index.php/Data_Structures#btrfs_file_extent_item > As you can see in the btrfs wiki, > disk_bytenr is *logical* address in btrfs linear space. Not really on disk > address. > > If you really want the address on device, you need to find the chunk > containing the address, > then the stripe in chunk item will show the raid profile and device address > on each device. > > Thanks, > Qu -- 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: Is it safe to mount subvolumes of already-mounted volumes (even with different options)?
Hi Sebastian,
I posted a similar question and got many helpful answers:
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg35047.html
Basically, you cannot guarantee that the computing mounting /dev/sdx
doesn't write to arbitrary addresses of /dev/sdxN as unallocated
blocks and thus corrupting the file system on it (I assume sdxN in
your example is a sub volume of sdx).
On Wed, Jul 16, 2014 at 6:18 PM, Sebastian Ochmann
wrote:
> Hello,
>
> I'm sharing a btrfs-formatted drive between multiple computers and each of
> the machines has a separate home directory on that drive. The root of the
> drive is mounted at /mnt/tray and the home directory for machine {hostname}
> is under /mnt/tray/Homes/{hostname}. Up until now, I have mounted /mnt/tray
> like a normal volume and then did an additional bind-mount of
> /mnt/tray/Homes/{hostname} to /home.
>
> Now I have a new drive and wanted to do things a bit more advanced by
> creating subvolumes for each of the machines' home directories so that I can
> also do independent snapshotting. I guess I could use the bind-mount method
> like before but my question is if it is considered safe to do an additional,
> "regular" mount of one of the subvolumes to /home instead, like
>
> mount /dev/sdxN /mnt/tray
> mount -o subvol=/Homes/{hostname} /dev/sdxN /home
>
> When I experimented with such additional mounts of subvolumes of
> already-mounted volumes, I noticed that the mount options of the additional
> subvolume mount might differ from the "original" mount. For instance, the
> root volume might be mounted with "noatime" while the subvolume mount may
> have "relatime".
>
> So my questions are: Is mounting a subvolume of an already mounted volume
> considered safe and are there any combinations of possibly conflicting mount
> options one should be aware of (compression, autodefrag, cache clearing)? Is
> it advisable to use the same mount options for all mounts pointing to the
> same physical device?
>
> Best regards,
> Sebastian
> --
> 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
--
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
