On 01/02/2011 08:52 PM, J G wrote:
> I just encountered some odd behavior from mkbtrfs.
> The end goal is to restore a backup to newly created BTRFS partitions while
> using the latest btrfs-tools.
> Here's the steps to what I did:
> * Booted SystemRescueCD
> * Partitioned the drives (two 750GB drives with 12 partitions each)
> * Created an extra partition on sda as a temporary holding place for the
> backed up files and so I can update btrfs-tools
> * Formatted/mounted/restored backup files to the temporary partition which I
> mounted on /mnt/backup
> * mount -t proc none /mnt/backup/proc; mount -o bind /dev /mnt/backup/dev
> * chroot /mnt/backup /bin/bash
> * Updated btrfs-tools to the latest git pull from today
> (v0.19-35-g1b444cd-dirty).
> * mkbtrfs /dev/sda5 /dev/sdb5 -L root
>
> mkbtrfs returned with:
>
> error checking /dev/sda5 mount status
>
> So I used strace to find out how it was checking for the mount status. Now,
> I'm no expert here, but I'm confused as to just why it failed. The last thing
> of note:
>
> lstat("/boot", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/boot/sysrcd.dat", 0x7fffb29681e0) = -1 ENOENT (No such file or
> directory)
> close(3) = 0
> munmap(0x7f11df372000, 4096) = 0
> write(2, "error checking /dev/sda5 mount s"..., 38error checking /dev/sda5
> mount status
> ) = 38
>
>
> doesn't explain much. I see that it's checking /proc/mounts to see what's
> mounted, and then it fails on stating /boot/sysrcd.dat (which doesn't exist
> in the non-chrooted FS, btw).
>
> To make this even weirder, if I format sda5/sdb5 using the SysRescCD version
> of mkbtrfs (v0.19) and then format sda5/sdb5 using the chroot version, it
> works fine.
>
> Any ideas here? I would expect that mkbtrfs would work inside of a chroot
> without any assistance from the original root.
>
> I have the full strace from the chrooted mkbtrfs failing and from it
> succeeding, if that's helpful.
On the basis of the provided information, and on the code it seems that
mkfs.btrfs tries hard to check that the user is not formatting a mounted
disk (or loop). So mkfs.btrfs scan the /proc/mount file and checks every
devices. To do the check it needs to access the original file if this is
a "loop backend". This is reasonable.
In this case in a chroot-ed environment the loop file is not accessible.
If you need a [dirty] "quick hack" to by-pass the problem (not tested):
- unmount the proc filesystem
- create an empty file /proc/mounts
- run btrfs.fsck
- mount the proc filesystem (removing the fake mounts file)
- perform a "btrfs device scan"
- mount the filesystem
Of course the "right" solution is to add a "--force" switch which
permits to by-pass these checks. Other mkfs.* tools have this switch.
>From the mkfs.ext4 man page:
[...]
-F Force mke2fs to create a filesystem,
even if the specified device is not
a partition on a block special
device, or if other parameters do
not make sense. In order to force
mke2fs to create a filesystem even
if the filesystem appears to be in
use or is mounted (a truly dangerous
thing to do), this option must be
specified twice.
[...]
>
> .:Justin:.
>
>
>
> --
> 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
