Re: [patch 01/99] btrfs: Add btrfs_panic()
On Thu, Nov 24, 2011 at 09:36:55PM -0500, Jeff Mahoney wrote: Probably best not to, it makes them inconsistent with the rest of the kernel's history when imported into git. The body becomes the commit text directly. I'll change them to do this since you're obviously correct. You're the first person in 10+ years to notice (or at least comment on) it, though. ;) Some maintainers (and Linus as well) appears to have just fixed them up when applying the patches. David -- 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: btrfs and load (sys)
On 24/11/11 12:00, Chris Samuel wrote: > You're running quite an old kernel btrfs wise - it would be > very interesting to see if you have the same issue with Linus's > current git version (which has the latest btrfs code) or > wait for 3.2-rc3. 3.2-rc3 is now out, Linus is after testers around the world because of some holiday in the US. cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: [patch 01/99] btrfs: Add btrfs_panic()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/24/2011 01:37 AM, David Brown wrote:
> On Wed, Nov 23, 2011 at 09:22:06PM -0500, Jeff Mahoney wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 11/23/2011 09:05 PM, David Brown wrote:
>>> On Wed, Nov 23, 2011 at 07:35:34PM -0500, Jeff Mahoney wrote:
As part of the effort to eliminate BUG_ON as an error
handling technique, we need to determine which errors are
actual logic errors, which are on-disk corruption, and which
are normal runtime errors e.g. -ENOMEM.
Annotating these error cases is helpful to understand and
report them.
This patch adds a btrfs_panic() routine that will either
panic or BUG depending on the new -ofatal_errors={panic,bug}
mount option. Since there are still so many BUG_ONs, it
defaults to BUG for now but I expect that to change once the
error handling effort has made significant progress.
>>>
>>> Any reason all of the commit text is indented in this series?
>>
>> Our internal patches have a bunch of RFC822-style headers
>> associated with them. For me, indenting the body is a style
>> thing. I like having the body appear separate from the headers.
>
> Probably best not to, it makes them inconsistent with the rest of
> the kernel's history when imported into git. The body becomes the
> commit text directly.
I'll change them to do this since you're obviously correct. You're the
first person in 10+ years to notice (or at least comment on) it,
though. ;)
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOzv9HAAoJEB57S2MheeWyTgsP+wUEW1gJkxyvuVymaL2qTXkz
ZFDzEIjzmb5x3/jt48yx+iD6ElshVUGYAimoeNkurBVPpi4lJ0n9ydpNm67To/cx
K9u2/5ld0/Ua+s8uTXjBxDQG/WSOPRk8pc3Y4gIIWyDn+dYQAUb5SvDc6/qWS0BS
aQT0faX1FO3g+Hp6ZbLbYgXa/5rqrm0L9Ek13f7bq6T8l3wzDlsgWnS8KtYhwnpr
4rPAU5eythJYj9OGMB34/YoOeDs61tJbbvvNW6TysdiEEdzqf6UQ1EF61r9G41aW
wXsA4f8oSYsM2t97eH5fGrk+0j2sXPf6CoxIG73DU51L3X4htY4fPc1SQyz0SwSR
t7CKt+ffT/oa9nCXuHsfwXZBCpDdIRFiVXgibL/rBX9akWXt61W9jZnZXISOU3QZ
kTOl9VaNAKCWfOMDbKq40cKbYANE16zQ37aXaWMilagsVHCkJH47HJJ17h0IlFqy
n+zu7++/iPYwclVxCEs/bUr4XyCxSDrqRsUM8s68u7BoZP3EWrmhtMmH11XXkg8e
iznttk4/lU8Chg0+yoS03tOQquOa3+y7rYgbq9r2h35f2tv1N+s4me8iO+hSJXwO
0vS7Akvf9n8583jd/y8F3UTl1G7obKAN7ooNURewHo0AzsmNVkK9FyK9SY07I1eS
w/Zu4uB9dQPxCqM5I5fm
=ZhyI
-END PGP SIGNATURE-
--
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: [patch 65/99] btrfs: ->submit_bio_hook error push-up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/24/2011 07:46 PM, David Sterba wrote:
> On Wed, Nov 23, 2011 at 07:36:38PM -0500, Jeff Mahoney wrote:
>> --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2752,10
>> +2759,12 @@ retry: static void flush_epd_write_bio(struct
>> extent_page_data *epd) { if (epd->bio) { + int ret; if
>> (epd->sync_io) - submit_one_bio(WRITE_SYNC, epd->bio, 0,
>> 0); +
>> ret = submit_one_bio(WRITE_SYNC, epd->bio, 0, 0); else -
>> submit_one_bio(WRITE, epd->bio, 0, 0); + ret =
>> submit_one_bio(WRITE, epd->bio, 0, 0); + BUG_ON(ret < 0);
>
> this if/else could be transfomed in the same way as in
>
> "63/99 btrfs: Simplify btrfs_submit_bio_hook"
>
> int rw = WRITE;
>
> if (epd->sync_io) rw = WRITE_SYNC;
>
> ret = submit_one_bio(rw, ...);
>
Yep. Thanks.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOzvrJAAoJEB57S2MheeWykzkP/R1hl05O57yxOTQXtYuJhvUF
RtL6RDD9nw/9QMWFHUXKFvaWtkuygi5BlcLKdXK0Zmsyk+hd7tzv8YfD1uLS2XS0
gioapvFNEmR6aRh1mMk6fJ429LiFgUrGGrCYQ28VTAgbe/RvMGedLAD6oqps5OJj
dsCkyUCBxl7ta6cFRlR37gj+rzKwDTEjRz3E2gx8oBjJWA/zXIoInBA+gEC1P3qn
YfmWyt31JwyOD3Oa2NQoCZGS7+MzotSe0RvAHbt5jc/DUDgJe+avv8Q5o4Bd2A7N
DAlAty/G8k9rUtEUOp53BclZdq2pDQ5hV/EEDMp743+Y5BoKTmpmXV1p4k7oVhvu
yOLTdYFtAo45c1pEeEzHm2GiowbdOemkmW3ySoFV8afRIVqkdgOfKMoUg6/c4B+o
StaAtihxBwSjZbmWSOtlwr8vHkqDK332nh5I6WF9OBcgEI4ZuH6GnmP2NEC5G9aj
03MFyyJuq53FBmM1CRHE94zc299ZwRxOxIkcSffR9Fm8ANXHlrELfXbVbkmWQf3e
bKs2skbAQmqbZE7yPbEHuN5vTElgP+MC56FBuVvJ+Lz4NO7HVV4KdfJKiM7J2QzA
qRsITdnnesKCfpkQTz4ShHZh+O3Y5ZgeP/wBNa9pK2+SZxA0HL3t8RaC/q/yjpYm
PBOaqH8nwVot+RBwI/Pv
=/8rB
-END PGP SIGNATURE-
--
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: [patch 13/99] btrfs: clear_extent_uptodate can drop gfp_t argumetn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2011 06:57 PM, David Sterba wrote: > Subject: Re: [patch 13/99] btrfs: clear_extent_uptodate can drop > gfp_t argumetn > > typo in subject s/argumetn/argument/, same in the next 2 patches > Thanks. Fixed. - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOzvoIAAoJEB57S2MheeWyQAUP/1bGJ04fHNzRGtscLj88YAHx 95AaqQUlf78kXT9nhX3VJIHF/SrQDbZ3wuHa4kXRTrvRivsRbRF+5S5UgANygtaG rCt+RgP5ZcK2W69gVJWMjcfWGSTn+o6GztDdTHueVzJz2ACemKZmrcrnOBp3Lbco FbhrB8KwzN+TLWF3uoZKtnrOgItVicischl8yJjik1rMhxGApPoFvEfmRXrHeyWA jo5zaLyE08VXw0BNT5SXxknVzgf5vjHAERVf+iiHj3kAFEM/A2iV10B/JtxKaE1r qEY+GZdKJ1ur8CsQggqYE/0adfzHdkIXFO22KyO2XhRtpmfh387azEhc3tA8JptR tCjp90od4ZnWHb+te2BcKgluNoZ1scxoB7R8mHCYSpjCBKeVtSGq1TevfC0l+GHp 7X5uO8PX8DbEiqboLdmqxhJjxdNX2jtH+9o2hgoUEPDfteDcwZ8oA2px7yT6wQXl TaiYmYxZCL2S656l6ylAwSxcZqPO910BbqsHGNntsKAZ0mJ1fRqj5Zzzlyl4fgqx TnOyG8YKP5GmQlA50naBY2V5Om3Ge3rEXxUbjPU9hhaJZPL4DnWvwgJ6PNKcZST+ lOkelnz+5mZX2dj1OhjQQQCKpXufk/I+TGKQ84VGn2oUtHePfIxr3Y6+BBOIl8BQ o1Ysr+N5VpMhY7GejIbT =Q/Yt -END PGP SIGNATURE- -- 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: [patch 03/99] btrfs: Panic on bad rbtree operations
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/24/2011 06:41 PM, David Sterba wrote:
> On Wed, Nov 23, 2011 at 07:35:36PM -0500, Jeff Mahoney wrote:
>> diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
>> index a1c9404..5a53d94 100644 --- a/fs/btrfs/ordered-data.c +++
>> b/fs/btrfs/ordered-data.c @@ -59,6 +59,14 @@ static struct
>> rb_node *tree_insert(struct rb_root *root, u64 file_offset,
>> return NULL; }
>>
>> +NORET_TYPE static void ordered_data_tree_panic(struct inode
>> *inode, int errno, +u64 offset) +{ +
>> struct
>> btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb)->fs_info; +
>> btrfs_panic(fs_info, errno, "Inconsistency in ordered tree at
>> offset " + "%llu\n", offset);
> this will need a cast to (unsigned long long)
>
>> +} + /* * look for a given offset in the tree, and if it can't be
>> found return the * first lesser offset ---
>> a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -326,6
>> +326,19 @@ static struct rb_node *tree_search(struct rb_root
>> *root, u64 bytenr) return NULL; }
>>
>> +NORET_TYPE static void backref_tree_panic(struct rb_node
>> *rb_node, int errno, + u64 bytenr)
>> +{ + +struct
>> btrfs_fs_info *fs_info = NULL; + struct backref_node *bnode =
>> rb_entry(rb_node, struct backref_node, +
>> rb_node); + if
>> (bnode->root) + fs_info = bnode->root->fs_info; +
>> btrfs_panic(fs_info, errno, "Inconsistency in backref cache " +
>> "found at offset %llu\n", bytenr);
>
> same here
>
>> +} +
>
Thanks. Fixed.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOzvm5AAoJEB57S2MheeWyQfcQAJXzeVYbLwLoJ0EqUSZBRzSZ
L5s4qWNTgdf6XVl4ZE8WgDJNDq1gMbdsjCug40QtQR8/f9btqbcz7oPnNeQDgfD8
PxZCiarOsm4fAiWDkchm/JDah9YTQCRzvV7Pg/362FnJJl7+a2muecvEMuXXgPdD
otE5BgYz7mJ5imZxpg3JnGwGXUhSiQD4tsprorY8A5I64QUSfGDBkdHNqRe2sVWn
PdN95UZb1z1wz3KZokslczJFsiOQkiOGurvnO+2J8L/+HH6pItKymT7j2F9q3EzQ
vtFP7tFFINfgdJUJyhpDRanhETfuAfwAuSqKVDFmujsPM38zdglSk3nXhh6yIucz
k067pYzHBA2gSJ2ZjRUgMlSMfcbiiYLuXhgFSMZosemoKBpn9RNW8hfxvX3kvBuh
w+oPmaOobRnwQV+ImPQlug2k7a1XpZUbrnJHoflbzEs2APrsmL863B4xHhb8vp+C
7SnlbGmW1Fk2vmsDfTWZHz7/Eb8atTZSdz3m/8lO6S420oBJ3xh7NIWq3sQLUnvg
+kDUfn3FjSRUwq4J/ETAf8fxarCuhDLpUo9MU11oaJ2qz50QUQI5W21bgrvBhbq7
fkQTZoAGirBIK3KIeV1cqeVDFkc5WilOc/moECX1Vicf1TUaUYe/A+Jko+6ObE5K
RH+fOkuY34cb34ccxV9r
=jxMY
-END PGP SIGNATURE-
--
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: [patch 65/99] btrfs: ->submit_bio_hook error push-up
On Wed, Nov 23, 2011 at 07:36:38PM -0500, Jeff Mahoney wrote:
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -2752,10 +2759,12 @@ retry:
> static void flush_epd_write_bio(struct extent_page_data *epd)
> {
> if (epd->bio) {
> + int ret;
> if (epd->sync_io)
> - submit_one_bio(WRITE_SYNC, epd->bio, 0, 0);
> + ret = submit_one_bio(WRITE_SYNC, epd->bio, 0, 0);
> else
> - submit_one_bio(WRITE, epd->bio, 0, 0);
> + ret = submit_one_bio(WRITE, epd->bio, 0, 0);
> + BUG_ON(ret < 0);
this if/else could be transfomed in the same way as in
"63/99 btrfs: Simplify btrfs_submit_bio_hook"
int rw = WRITE;
if (epd->sync_io)
rw = WRITE_SYNC;
ret = submit_one_bio(rw, ...);
--
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: [patch 13/99] btrfs: clear_extent_uptodate can drop gfp_t argumetn
Subject: Re: [patch 13/99] btrfs: clear_extent_uptodate can drop gfp_t argumetn typo in subject s/argumetn/argument/, same in the next 2 patches -- 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: [patch 03/99] btrfs: Panic on bad rbtree operations
On Wed, Nov 23, 2011 at 07:35:36PM -0500, Jeff Mahoney wrote:
> diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
> index a1c9404..5a53d94 100644
> --- a/fs/btrfs/ordered-data.c
> +++ b/fs/btrfs/ordered-data.c
> @@ -59,6 +59,14 @@ static struct rb_node *tree_insert(struct rb_root *root,
> u64 file_offset,
> return NULL;
> }
>
> +NORET_TYPE static void ordered_data_tree_panic(struct inode *inode, int
> errno,
> +u64 offset)
> +{
> + struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb)->fs_info;
> + btrfs_panic(fs_info, errno, "Inconsistency in ordered tree at offset "
> + "%llu\n", offset);
this will need a cast to (unsigned long long)
> +}
> +
> /*
> * look for a given offset in the tree, and if it can't be found return the
> * first lesser offset
> --- a/fs/btrfs/relocation.c
> +++ b/fs/btrfs/relocation.c
> @@ -326,6 +326,19 @@ static struct rb_node *tree_search(struct rb_root *root,
> u64 bytenr)
> return NULL;
> }
>
> +NORET_TYPE static void backref_tree_panic(struct rb_node *rb_node, int errno,
> + u64 bytenr)
> +{
> +
> + struct btrfs_fs_info *fs_info = NULL;
> + struct backref_node *bnode = rb_entry(rb_node, struct backref_node,
> + rb_node);
> + if (bnode->root)
> + fs_info = bnode->root->fs_info;
> + btrfs_panic(fs_info, errno, "Inconsistency in backref cache "
> + "found at offset %llu\n", bytenr);
same here
> +}
> +
--
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: mount errors
After reboot my partition table was gone, and neither gpart og testdisk could recover it. Sad. Even though the missing partition table right after upgrading btrfs-tools is a coincidence, I will wait a while before giving btrfs another chance. Best of luck with creating a fsck for this promising file system. -René On 22 November 2011 15:24, René Vangsgaard wrote: > I did a reboot, and now I am trying to recover from a disk with no > partition table. Currently gpart has been running for 30 mins - stupid > me for not printing the partition table. > > I did nothing more than executing "make" and "make install" in ./btrs-progs/. > > On 22 November 2011 13:56, Jan Schmidt wrote: >> On 22.11.2011 14:26, René Vangsgaard wrote: >>> I got the build working by changing -lpthread to -pthread in the gcc call: >>> >>> gcc -pthread -g -O0 -o btrfs btrfs.o btrfs_cmds.o scrub.o ctree.o >>> disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o >>> dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o >>> extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfslabel.o >>> -luuid >>> >>> Using -lpthread gave a build error. I will now reboot and have a look... >> >> We've already queued a fix for that, it's just not pushed out yet. >> -Jan >> > -- 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: btrfs encryption problems
On Thu, 24 Nov 2011 21:43:50 + 810d4rk <810d...@gmail.com> wrote: > > These printks indicate that the encryption or password is not the same as > > used when creating the device. > > So at this stage, this has nothing to do with btrfs. > > No, Ive decrypted the volume with the password, I can confirm it and > also I haven't change it, BTW I have some new output from the kernel > when trying to mount it: > > [21754.913248] usb 2-1.1: new high speed USB device number 20 using ehci_hcd > [21755.119495] scsi45 : usb-storage 2-1.1:1.0 > [21757.616505] scsi 45:0:0:0: Direct-Access WDC WD75 > 00BPVT-22HXZT1 01.0 PQ: 0 ANSI: 5 > [21757.633275] sd 45:0:0:0: Attached scsi generic sg4 type 0 > [21757.634765] sd 45:0:0:0: [sdc] 1465149168 512-byte logical blocks: > (750 GB/698 GiB) > [21757.635789] sd 45:0:0:0: [sdc] Write Protect is off > [21757.635798] sd 45:0:0:0: [sdc] Mode Sense: 43 00 00 00 > [21757.637434] sd 45:0:0:0: [sdc] Write cache: disabled, read cache: > enabled, doesn't support DPO or FUA > [21757.727481] sdc: sdc1 > [21757.730497] sd 45:0:0:0: [sdc] Attached SCSI disk > [21757.737422] sd 45:0:0:0: [sdc] Sense Key : Recovered Error > [current] [descriptor] > [21757.737438] Descriptor sense data with sense descriptors (in hex): > [21757.737443] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 57 00 > [21757.737462] 00 00 00 00 00 50 > [21757.737472] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d > [21757.868565] sd 45:0:0:0: [sdc] Sense Key : Recovered Error > [current] [descriptor] > [21757.868580] Descriptor sense data with sense descriptors (in hex): > [21757.868585] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 > [21757.868604] 00 00 00 00 00 50 > [21757.868614] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d > [21777.246960] EXT3-fs (dm-1): error: can't find ext3 filesystem on dev dm-1. > [21777.283216] EXT2-fs (dm-1): error: can't find an ext2 filesystem on dev > dm-1. > [21777.338992] EXT4-fs (dm-1): VFS: Can't find ext4 filesystem > [21777.456509] REISERFS warning (device dm-1): sh-2021 > reiserfs_fill_super: can not find reiserfs on dm-1 > [21777.503417] XFS (dm-1): bad magic number > [21777.503428] XFS (dm-1): SB validate failed > [21777.622915] FAT-fs (dm-1): bogus number of reserved sectors > [21777.622926] FAT-fs (dm-1): Can't find a valid FAT filesystem > [21777.663109] FAT-fs (dm-1): bogus number of reserved sectors > [21777.663120] FAT-fs (dm-1): Can't find a valid FAT filesystem My mistake, the same printks are printed when the encryption key is incorrect, I've seen that here. It looks like you have some ugly hardware errors. The kernel cannot read from the drive, so it cannot guess the file system on it. If the data is valuable, you could try to ddrescue the drive to a bigger one. (>750GB... and that will take time...) and attempt to mount the rescued data. If the drive is in an USB enclosure, you could plug it directly via SATA to the system (maybe it has issues?). ++ -- cJ -- 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: btrfs encryption problems
> These printks indicate that the encryption or password is not the same as > used when creating the device. > So at this stage, this has nothing to do with btrfs. No, Ive decrypted the volume with the password, I can confirm it and also I haven't change it, BTW I have some new output from the kernel when trying to mount it: [21754.913248] usb 2-1.1: new high speed USB device number 20 using ehci_hcd [21755.119495] scsi45 : usb-storage 2-1.1:1.0 [21757.616505] scsi 45:0:0:0: Direct-Access WDC WD75 00BPVT-22HXZT1 01.0 PQ: 0 ANSI: 5 [21757.633275] sd 45:0:0:0: Attached scsi generic sg4 type 0 [21757.634765] sd 45:0:0:0: [sdc] 1465149168 512-byte logical blocks: (750 GB/698 GiB) [21757.635789] sd 45:0:0:0: [sdc] Write Protect is off [21757.635798] sd 45:0:0:0: [sdc] Mode Sense: 43 00 00 00 [21757.637434] sd 45:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [21757.727481] sdc: sdc1 [21757.730497] sd 45:0:0:0: [sdc] Attached SCSI disk [21757.737422] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21757.737438] Descriptor sense data with sense descriptors (in hex): [21757.737443] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 57 00 [21757.737462] 00 00 00 00 00 50 [21757.737472] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21757.868565] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21757.868580] Descriptor sense data with sense descriptors (in hex): [21757.868585] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 [21757.868604] 00 00 00 00 00 50 [21757.868614] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21777.246960] EXT3-fs (dm-1): error: can't find ext3 filesystem on dev dm-1. [21777.283216] EXT2-fs (dm-1): error: can't find an ext2 filesystem on dev dm-1. [21777.338992] EXT4-fs (dm-1): VFS: Can't find ext4 filesystem [21777.456509] REISERFS warning (device dm-1): sh-2021 reiserfs_fill_super: can not find reiserfs on dm-1 [21777.503417] XFS (dm-1): bad magic number [21777.503428] XFS (dm-1): SB validate failed [21777.622915] FAT-fs (dm-1): bogus number of reserved sectors [21777.622926] FAT-fs (dm-1): Can't find a valid FAT filesystem [21777.663109] FAT-fs (dm-1): bogus number of reserved sectors [21777.663120] FAT-fs (dm-1): Can't find a valid FAT filesystem [21788.328298] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21788.328312] Descriptor sense data with sense descriptors (in hex): [21788.328317] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 [21788.328335] 00 00 00 00 00 50 [21788.328345] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21788.342307] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21788.342323] Descriptor sense data with sense descriptors (in hex): [21788.342329] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 [21788.342353] 00 4f 00 c2 00 50 [21788.342366] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21788.354571] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21788.354587] Descriptor sense data with sense descriptors (in hex): [21788.354592] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 [21788.354611] 00 00 00 00 00 50 [21788.354620] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21790.015454] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21790.015469] Descriptor sense data with sense descriptors (in hex): [21790.015473] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 [21790.015492] 00 4f 00 c2 00 50 [21790.015502] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21828.295120] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5] [21828.295128] ecryptfs_writepage: Error encrypting page (upper index [0x0009]) [21828.295186] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5] [21828.295190] ecryptfs_writepage: Error encrypting page (upper index [0x0009]) [21828.295246] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5] [21828.295250] ecryptfs_writepage: Error encrypting page (upper index [0x0009]) -- Thanks -- 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: btrfs encryption problems
On Wed, 23 Nov 2011 19:38:37 + 810d4rk <810d...@gmail.com> wrote: > [ 4836.897206] sd 20:0:0:0: [sdc] Attached SCSI disk > [ 4844.803652] EXT3-fs (dm-1): error: can't find ext3 filesystem on dev dm-1. > [ 4844.856054] EXT2-fs (dm-1): error: can't find an ext2 filesystem on dev > dm-1. > [ 4844.902679] EXT4-fs (dm-1): VFS: Can't find ext4 filesystem > [ 4932.637108] EXT3-fs (dm-1): error: can't find ext3 filesystem on dev dm-1. > [ 4932.686841] EXT2-fs (dm-1): error: can't find an ext2 filesystem on dev > dm-1. > [ 4932.738999] EXT4-fs (dm-1): VFS: Can't find ext4 filesystem > [ 4949.142867] EXT3-fs (dm-1): error: can't find ext3 filesystem on dev dm-1. > [ 4949.197596] EXT2-fs (dm-1): error: can't find an ext2 filesystem on dev > dm-1. > [ 4949.241721] EXT4-fs (dm-1): VFS: Can't find ext4 filesystem These printks indicate that the encryption or password is not the same as used when creating the device. So at this stage, this has nothing to do with btrfs. > In my experience btrfs + encryption eats the data, this is not the > first time I had this problem with btrfs so I am considering switching > to ext4, but can I still get the other data back on the broken btrfs?? Don't worry, btrfs doesn't need encryption to eat your data. If you use it, keep backups. Good luck with getting back the data ! -- cJ -- 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: btrfs encryption problems
Now when I tried to mount the disk I get this: Error mounting: mount exited with exit code 12: NTFS signature is missing. Failed to mount '/dev/mapper/udisks-luks-uuid-269300fe-1329-42f8-b7fa-4a399a71d56f-uid1000': Invalid argument The device '/dev/mapper/udisks-luks-uuid-269300fe-1329-42f8-b7fa-4a399a71d56f-uid1000' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? Can anyone help? On 23/11/2011, 810d4rk <810d...@gmail.com> wrote: >> dd that backup disk to another disk, so you have a backup of your >> backup, and work with that. > > OK. > >> You can also post the dmesg output you get when you mount the broken >> filesystem, and ask the experts if it might be worth to try experimental >> btrfs.fsck on it. > > dmesg does not output anything of value since the file system is not > detectable, here is the kernel output: > > [ 4834.149123] usb 2-1.1: new high speed USB device number 12 using > ehci_hcd > [ 4834.245114] scsi20 : usb-storage 2-1.1:1.0 > [ 4835.246193] scsi 20:0:0:0: Direct-Access WDC WD75 > 00BPVT-22HXZT1 1A01 PQ: 0 ANSI: 2 CCS > [ 4835.317195] sd 20:0:0:0: Attached scsi generic sg4 type 0 > [ 4835.317889] sd 20:0:0:0: [sdc] 1465149168 512-byte logical blocks: > (750 GB/698 GiB) > [ 4835.318944] sd 20:0:0:0: [sdc] Write Protect is off > [ 4835.318956] sd 20:0:0:0: [sdc] Mode Sense: 00 38 00 00 > [ 4835.320603] sd 20:0:0:0: [sdc] Asking for cache data failed > [ 4835.320619] sd 20:0:0:0: [sdc] Assuming drive cache: write through > [ 4835.324143] sd 20:0:0:0: [sdc] Asking for cache data failed > [ 4835.324153] sd 20:0:0:0: [sdc] Assuming drive cache: write through > [ 4836.894263] sdc: sdc1 > [ 4836.897190] sd 20:0:0:0: [sdc] Asking for cache data failed > [ 4836.897200] sd 20:0:0:0: [sdc] Assuming drive cache: write through > [ 4836.897206] sd 20:0:0:0: [sdc] Attached SCSI disk > [ 4844.803652] EXT3-fs (dm-1): error: can't find ext3 filesystem on dev > dm-1. > [ 4844.856054] EXT2-fs (dm-1): error: can't find an ext2 filesystem on dev > dm-1. > [ 4844.902679] EXT4-fs (dm-1): VFS: Can't find ext4 filesystem > [ 4932.637108] EXT3-fs (dm-1): error: can't find ext3 filesystem on dev > dm-1. > [ 4932.686841] EXT2-fs (dm-1): error: can't find an ext2 filesystem on dev > dm-1. > [ 4932.738999] EXT4-fs (dm-1): VFS: Can't find ext4 filesystem > [ 4949.142867] EXT3-fs (dm-1): error: can't find ext3 filesystem on dev > dm-1. > [ 4949.197596] EXT2-fs (dm-1): error: can't find an ext2 filesystem on dev > dm-1. > [ 4949.241721] EXT4-fs (dm-1): VFS: Can't find ext4 filesystem > >> fwiw, I backup to gpg encrypted files stored on ext4 to cope with >> regressions in both btrfs and disk encryption. > > > In my experience btrfs + encryption eats the data, this is not the > first time I had this problem with btrfs so I am considering switching > to ext4, but can I still get the other data back on the broken btrfs?? > > -- > Thanks > -- Thanks -- 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
[PATCH] btrfs: reduce btrfs_path size
Reduce size of struct btrfs_path from 144 to 96 bytes and save one
cacheline. This will allow packing of 42 objects into a PAGE_SIZE slab,
(previously 28, measured on x86_64).
Let 'slots' hold at most 65536, which is enough to index items for
reasonably big blocksizes (4k, 64k).
Maximum is 2M: 65536 * 33 (sizeof struct btrfs_key_ptr)
(Making it u8 would allow only 256 * 33 = 8448 ie 8k blocksize)
A 'locks' item holds at most 5 values of lock type.
'lowest_level': maximum level is 8
The 'reada' is set to {-1,0,1,2}, has to be signed.
Signed-off-by: David Sterba
---
fs/btrfs/ctree.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 04a5dfc..0b5bd2c 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -514,12 +514,12 @@ struct btrfs_node {
*/
struct btrfs_path {
struct extent_buffer *nodes[BTRFS_MAX_LEVEL];
- int slots[BTRFS_MAX_LEVEL];
+ u16 slots[BTRFS_MAX_LEVEL];
/* if there is real range locking, this locks field will change */
- int locks[BTRFS_MAX_LEVEL];
- int reada;
+ u8 locks[BTRFS_MAX_LEVEL];
/* keep some upper locks as we walk down */
- int lowest_level;
+ u8 lowest_level;
+ s8 reada; /* sign represents direction */
/*
* set by btrfs_split_item, tells search_slot to keep all locks
--
1.7.6
--
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
[PATCH] btrfs: polish names of kmem caches
Usecase:
watch 'grep btrfs < /proc/slabinfo'
easy to watch all caches in one go.
Signed-off-by: David Sterba
---
fs/btrfs/delayed-inode.c |2 +-
fs/btrfs/extent_io.c |4 ++--
fs/btrfs/extent_map.c|2 +-
fs/btrfs/inode.c | 10 +-
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index b52c672..5ed6162 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -29,7 +29,7 @@ static struct kmem_cache *delayed_node_cache;
int __init btrfs_delayed_inode_init(void)
{
- delayed_node_cache = kmem_cache_create("delayed_node",
+ delayed_node_cache = kmem_cache_create("btrfs_delayed_node",
sizeof(struct btrfs_delayed_node),
0,
SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD,
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index a255136..4d57aaa 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -53,13 +53,13 @@ struct extent_page_data {
int __init extent_io_init(void)
{
- extent_state_cache = kmem_cache_create("extent_state",
+ extent_state_cache = kmem_cache_create("btrfs_extent_state",
sizeof(struct extent_state), 0,
SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD, NULL);
if (!extent_state_cache)
return -ENOMEM;
- extent_buffer_cache = kmem_cache_create("extent_buffers",
+ extent_buffer_cache = kmem_cache_create("btrfs_extent_buffer",
sizeof(struct extent_buffer), 0,
SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD, NULL);
if (!extent_buffer_cache)
diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
index 7c97b33..08a8c40 100644
--- a/fs/btrfs/extent_map.c
+++ b/fs/btrfs/extent_map.c
@@ -11,7 +11,7 @@ static struct kmem_cache *extent_map_cache;
int __init extent_map_init(void)
{
- extent_map_cache = kmem_cache_create("extent_map",
+ extent_map_cache = kmem_cache_create("btrfs_extent_map",
sizeof(struct extent_map), 0,
SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD, NULL);
if (!extent_map_cache)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index be589cc..d091166 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -6866,31 +6866,31 @@ void btrfs_destroy_cachep(void)
int btrfs_init_cachep(void)
{
- btrfs_inode_cachep = kmem_cache_create("btrfs_inode_cache",
+ btrfs_inode_cachep = kmem_cache_create("btrfs_inode",
sizeof(struct btrfs_inode), 0,
SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD, init_once);
if (!btrfs_inode_cachep)
goto fail;
- btrfs_trans_handle_cachep =
kmem_cache_create("btrfs_trans_handle_cache",
+ btrfs_trans_handle_cachep = kmem_cache_create("btrfs_trans_handle",
sizeof(struct btrfs_trans_handle), 0,
SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD, NULL);
if (!btrfs_trans_handle_cachep)
goto fail;
- btrfs_transaction_cachep = kmem_cache_create("btrfs_transaction_cache",
+ btrfs_transaction_cachep = kmem_cache_create("btrfs_transaction",
sizeof(struct btrfs_transaction), 0,
SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD, NULL);
if (!btrfs_transaction_cachep)
goto fail;
- btrfs_path_cachep = kmem_cache_create("btrfs_path_cache",
+ btrfs_path_cachep = kmem_cache_create("btrfs_path",
sizeof(struct btrfs_path), 0,
SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD, NULL);
if (!btrfs_path_cachep)
goto fail;
- btrfs_free_space_cachep = kmem_cache_create("btrfs_free_space_cache",
+ btrfs_free_space_cachep = kmem_cache_create("btrfs_free_space",
sizeof(struct btrfs_free_space), 0,
SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD, NULL);
if (!btrfs_free_space_cachep)
--
1.7.6
--
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
[PATCH v2] Btrfs: rewrite btrfs_trim_block_group()
There are various bugs in block group trimming:
- It may trim from offset smaller than user-specified offset.
- It may trim beyond user-specified range.
- It may leak free space for extents smaller than specified minlen.
- It may truncate the last trimmed extent thus leak free space.
- With mixed extents+bitmaps, some extents may not be trimmed.
- With mixed extents+bitmaps, some bitmaps may not be trimmed (even
none will be trimmed). Even for those trimmed, not all the free space
in the bitmaps will be trimmed.
I rewrite btrfs_trim_block_group() and break it into two functions.
One is to trim extents only, and the other is to trim bitmaps only.
Signed-off-by: Li Zefan
---
v2: fix possible uninitialized return value
---
fs/btrfs/free-space-cache.c | 235 ++-
1 files changed, 164 insertions(+), 71 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 6e5b7e4..bd2a3cd 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -2586,17 +2586,57 @@ void btrfs_init_free_cluster(struct btrfs_free_cluster
*cluster)
cluster->block_group = NULL;
}
-int btrfs_trim_block_group(struct btrfs_block_group_cache *block_group,
- u64 *trimmed, u64 start, u64 end, u64 minlen)
+static int do_trimming(struct btrfs_block_group_cache *block_group,
+ u64 *total_trimmed, u64 start, u64 bytes,
+ u64 reserved_start, u64 reserved_bytes)
{
- struct btrfs_free_space_ctl *ctl = block_group->free_space_ctl;
- struct btrfs_free_space *entry = NULL;
+ struct btrfs_space_info *space_info = block_group->space_info;
struct btrfs_fs_info *fs_info = block_group->fs_info;
- u64 bytes = 0;
- u64 actually_trimmed;
- int ret = 0;
+ int ret;
+ int update = 0;
+ u64 trimmed = 0;
- *trimmed = 0;
+ spin_lock(&space_info->lock);
+ spin_lock(&block_group->lock);
+ if (!block_group->ro) {
+ block_group->reserved += reserved_bytes;
+ space_info->bytes_reserved += reserved_bytes;
+ update = 1;
+ }
+ spin_unlock(&block_group->lock);
+ spin_unlock(&space_info->lock);
+
+ ret = btrfs_error_discard_extent(fs_info->extent_root,
+start, bytes, &trimmed);
+ if (!ret)
+ *total_trimmed += trimmed;
+
+ btrfs_add_free_space(block_group, reserved_start, reserved_bytes);
+
+ if (update) {
+ spin_lock(&space_info->lock);
+ spin_lock(&block_group->lock);
+ if (block_group->ro)
+ space_info->bytes_readonly += reserved_bytes;
+ block_group->reserved -= reserved_bytes;
+ space_info->bytes_reserved -= reserved_bytes;
+ spin_unlock(&space_info->lock);
+ spin_unlock(&block_group->lock);
+ }
+
+ return ret;
+}
+
+static int trim_no_bitmap(struct btrfs_block_group_cache *block_group,
+ u64 *total_trimmed, u64 start, u64 end, u64 minlen)
+{
+ struct btrfs_free_space_ctl *ctl = block_group->free_space_ctl;
+ struct btrfs_free_space *entry;
+ struct rb_node *node;
+ int ret = 0;
+ u64 extent_start;
+ u64 extent_bytes;
+ u64 bytes;
while (start < end) {
spin_lock(&ctl->tree_lock);
@@ -2607,81 +2647,118 @@ int btrfs_trim_block_group(struct
btrfs_block_group_cache *block_group,
}
entry = tree_search_offset(ctl, start, 0, 1);
- if (!entry)
- entry = tree_search_offset(ctl,
- offset_to_bitmap(ctl, start),
- 1, 1);
-
- if (!entry || entry->offset >= end) {
+ if (!entry) {
spin_unlock(&ctl->tree_lock);
break;
}
- if (entry->bitmap) {
- ret = search_bitmap(ctl, entry, &start, &bytes);
- if (!ret) {
- if (start >= end) {
- spin_unlock(&ctl->tree_lock);
- break;
- }
- bytes = min(bytes, end - start);
- bitmap_clear_bits(ctl, entry, start, bytes);
- if (entry->bytes == 0)
- free_bitmap(ctl, entry);
- } else {
- start = entry->offset + BITS_PER_BITMAP *
- block_group->sectorsize;
+ /* skip bitmaps */
+ while (entry->bitmap) {
+ node = rb_next(&entry->offset_inde
