From: Jan Schmidt <list.btrfs@jan-o-sch.net>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Broken DIR_ITEMs on snapshot
Date: Tue, 18 Oct 2011 18:01:11 +0200 [thread overview]
Message-ID: <4E9DA2C7.90309@jan-o-sch.net> (raw)
Hi,
while still busy with btrfs send, I came across some strange DIR_ITEMs.
I looked into that briefly, but I'd rather return to implementing btrfs
send, hoping someone is willing to make up his mind on this one :-)
To reproduce, do the following:
# mkfs.btrfs /dev/sdv2
# mount /dev/sdv2 /mnt
# btrfs subvol snap /mnt /mnt/snap1
You've a freshly created snapshot. However, file tree 256 (the
snap1-tree) will contain two strange items:
item 2 key (256 DIR_ITEM 3645318598) itemoff 3788 itemsize 35
location key (256 ROOT_ITEM 18446744073709551615) type 2
namelen 5 datalen 0 name: snap1
item 3 key (256 DIR_INDEX 2) itemoff 3753 itemsize 35
location key (256 ROOT_ITEM 18446744073709551615) type 2
namelen 5 datalen 0 name: snap1
These items are needed in tree 5 (fs tree) to reference snap1. However,
within snap1, I'd not expect the entries. A brief look into
create_pending_snapshot reveals
...
btrfs_insert_dir_item()
...
/* some delayed stuff with scary comments */
...
btrfs_cow_block()
...
I'm not sure whether cowing earlier would help, I'm particularly
uncertain because of the run_delayed_* code in between. So I haven't
tried to fix this, I'm convinced it should be fixed, though.
These items lead to some strange effects:
# cd /mnt/snap1
# ls -l
dr-xr-xr-x 1 root root 10 Jan 1 1970 .
dr-xr-xr-x 1 root root 16 Oct 18 15:56 ..
# mkdir snap1
mkdir: cannot create directory `snap1': File exists
# stat snap1
File: `snap1'
Size: 0 Blocks: 0 IO Block: 4096 directory
Device: 11h/17d Inode: 2 Links: 1
# rmdir snap1
# stat snap1
stat: cannot stat `snap1': No such file or directory
Inode number 2 seems to be BTRFS_EMPTY_SUBVOL_DIR_OBJECTID, the pseudo
object is created by btrfs_lookup_dentry() in inode.c when ENOENT is
encountered.
As a side note: the timestamp of the snap-dir item could be prettier.
No such pseudo items are created when the snapshot is placed outside of
the subvolume to be snapshotted, obviously. In the above example, do ...
# btrfs subvol snap /mnt/snap1 /mnt/snap2
... and no such items will be created, which makes me quite certain the
existence of above mentioned DIR_ITEMs is a bug, isn't it?
-Jan
next reply other threads:[~2011-10-18 16:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-18 16:01 Jan Schmidt [this message]
2011-10-18 18:51 ` Broken DIR_ITEMs on snapshot Ilya Dryomov
2011-10-19 10:17 ` Jan Schmidt
2011-10-19 12:57 ` Chris Mason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E9DA2C7.90309@jan-o-sch.net \
--to=list.btrfs@jan-o-sch.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.