Re: [PATCH 02/20] Btrfs: initialize new bitmaps' list
2011/12/12 Alexandre Oliva ol...@lsd.ic.unicamp.br: On Dec 7, 2011, Christian Brunner c...@muc.de wrote: With this patch applied I get much higher write-io values than without it. Some of the other patches help to reduce the effect, but it's still significant. iostat on an unpatched node is giving me: Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 105.90 0.37 15.42 14.48 2657.33 560.13 107.61 1.89 62.75 6.26 18.71 while on a node with this patch it's sda 128.20 0.97 11.10 57.15 3376.80 552.80 57.58 20.58 296.33 4.16 28.36 Also interesting, is the fact that the average request size on the patched node is much smaller. That's probably expected for writes, as bitmaps are expected to be more fragmented, even if used only for metadata (or are you on SSD?) It's a traditional hardware RAID5 with spinning disks. - I would accept this if the writes would start right after the mount, but in this case it takes a few hours until the writes increase. Thats why I'm allmost certain that something is still wrong. Bitmaps are just a different in-memory (and on-disk-cache, if enabled) representation of free space, that can be far more compact: one bit per disk block, rather than an extent list entry. They're interchangeable otherwise, it's just that searching bitmaps for a free block (bit) is somewhat more expensive than taking the next entry from a list, but you don't want to use up too much memory with long lists of e.g. single-block free extents. Thanks for the explanation! I'll try to insert some debuging code, once my test server is ready. Christian -- 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 2/3] Btrfs: add ioctl to get and reset the device stats
On 12/11/2011 11:24 AM, Goffredo Baroncelli wrote:
On Friday, 09 December, 2011 17:40:27 Stefan Behrens wrote:
An ioctl interface is added to get the device statistic counters.
A second ioctl is added to atomically get and reset these counters.
[...]
+static long btrfs_ioctl_get_device_stats(struct btrfs_root *root,
+ void __user *arg, int reset_after_read)
+{
+struct btrfs_ioctl_get_device_stats *sa;
+int ret;
+
+if (!capable(CAP_SYS_ADMIN))
+return -EPERM;
+
I agree that the BTRFS_IOC_GET_AND_RESET_DEVICE_STATS should be a privileged
operation. But I think that the BTRFS_IOC_GET_DEVICE_STATS should be allowed
to everyone. Think about a daemon which look at the error, and then send an
email to warn about possible defect. Allowing BTRFS_IOC_GET_DEVICE_STATS to
everyone, prevent to run the deamon with root privileges.
I fully agree to your comment and will change it in a v2. 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: [PATCH] Btrfs-progs: fail gracefully on error from open_ctree()
On Tue, Nov 01, 2011 at 11:47:22PM +0200, Ilya Dryomov wrote:
--- a/mkfs.c
+++ b/mkfs.c
@@ -1328,7 +1328,12 @@ int main(int ac, char **av)
fprintf(stderr, error during mkfs %d\n, ret);
exit(1);
}
+
root = open_ctree(file, 0, O_RDWR);
+ if (!root) {
+ fprintf(stderr, ctree init failed\n);
+ return -1;
I know you just moved the code, but this should be exit(1), same as the
rest of the function does
+ }
root-fs_info-alloc_start = alloc_start;
ret = make_root_dir(root, mixed);
@@ -1343,10 +1348,6 @@ int main(int ac, char **av)
goto raid_groups;
btrfs_register_one_device(file);
- if (!root) {
- fprintf(stderr, ctree init failed\n);
- return -1;
- }
zero_end = 1;
while(ac-- 0) {
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: [PATCH] Btrfs-progs: fail gracefully on error from open_ctree()
On Mon, Dec 12, 2011 at 03:40:19PM +0100, David Sterba wrote:
On Tue, Nov 01, 2011 at 11:47:22PM +0200, Ilya Dryomov wrote:
--- a/mkfs.c
+++ b/mkfs.c
@@ -1328,7 +1328,12 @@ int main(int ac, char **av)
fprintf(stderr, error during mkfs %d\n, ret);
exit(1);
}
+
root = open_ctree(file, 0, O_RDWR);
+ if (!root) {
+ fprintf(stderr, ctree init failed\n);
+ return -1;
I know you just moved the code, but this should be exit(1), same as the
rest of the function does
I updated the patch.
Thanks,
Ilya
--
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
Consistent crash with cp reflink on large files
Hi All, I have been encountering consistent btrfs filesystem crashes when using cp –reflink=always on a large file and modifying it. I believe that the test file needs to be fairly large as I was not able to reproduce with smaller files. The filesystem size is 45GB and file size is 10GB. Thanks, Nik Trace: [240213.884228] [ cut here ] [240213.884232] kernel BUG at /build/buildd/linux-3.0.0/fs/btrfs/delayed-inode.c:1693! [240213.884235] invalid opcode: [#1] SMP [240213.884237] Modules linked in: bnep rfcomm bluetooth vboxnetadp vboxnetflt vboxdrv binfmt_misc nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc vesafb snd_hda_codec_analog snd_usb_audio snd_usbmidi_lib joydev snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event dell_wmi sparse_keymap ppdev snd_seq snd_timer snd_seq_device nvidia(P) dcdbas wmi parport_pc psmouse snd serio_raw soundcore snd_page_alloc i7core_edac edac_core lp parport usbhid hid firewire_ohci firewire_core crc_itu_t tg3 btrfs zlib_deflate libcrc32c [240213.884266] [240213.884269] Pid: 4703, comm: cp Tainted: P 3.0.0-13-generic #22-Ubuntu Dell Inc. Precision WorkStation T3500 /0XPDFK [240213.884273] EIP: 0060:[f8164ca0] EFLAGS: 00010286 CPU: 0 [240213.884289] EIP is at btrfs_delayed_update_inode+0x100/0x110 [btrfs] [240213.884291] EAX: ffe4 EBX: eb555e08 ECX: 00018000 EDX: 00018000 [240213.884293] ESI: eb4d8db0 EDI: eb41089c EBP: f1e0dde8 ESP: f1e0ddc8 [240213.884295] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [240213.884297] Process cp (pid: 4703, ti=f1e0c000 task=eba03fc0 task.ti=f1e0c000) [240213.884299] Stack: [240213.884300] 00018000 00018000 edd74800 eb555e34 eb41089c edd74800 [240213.884305] f1e0de10 f81202a8 0001 eb40c11c f6b18150 eb4d8db0 eb41089c [240213.884309] edd74800 f1e0df04 f8148e16 067ff000 0001 02599000 [240213.884314] Call Trace: [240213.884328] [f81202a8] btrfs_update_inode+0x58/0x170 [btrfs] [240213.884342] [f8148e16] btrfs_ioctl_clone+0x936/0xc60 [btrfs] [240213.884357] [f814cb30] btrfs_ioctl+0x570/0x5e0 [btrfs] [240213.884371] [f814c5c0] ? btrfs_ioctl_trans_end+0x60/0x60 [btrfs] [240213.884375] [c11380ea] file_ioctl+0x4a/0x150 [240213.884377] [c11384ba] do_vfs_ioctl+0x2ca/0x2d0 [240213.884380] [c113852f] sys_ioctl+0x6f/0x80 [240213.884383] [c152cc24] syscall_call+0x7/0xb [240213.884385] Code: 46 24 89 0c 24 81 c2 b0 00 00 00 89 4d e8 e8 28 27 fa ff 8b 4d e8 85 c0 75 11 89 4b 08 c7 43 0c 00 00 00 00 e9 49 ff ff ff 66 90 0f 0b 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 53 3e [240213.884411] EIP: [f8164ca0] btrfs_delayed_update_inode+0x100/0x110 [btrfs] SS:ESP 0068:f1e0ddc8 [240213.884500] ---[ end trace 81327a383209814e ]--- System: 3.0.0-13-generic #22-Ubuntu SMP, 32-bit, http://www.dell.com/us/business/p/precision-t3500/pd, Xeon W3503, --- other info sudo hdparm -I /dev/sda /dev/sda: ATA device, with non-removable media Model Number: WDC WD2500AAJS-75M0A0 Serial Number: WD-WMAV2W142610 Firmware Revision: 02.03E02 Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5 Standards: Supported: 8 7 6 5 Likely used: 8 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBAuser addressable sectors: 268435455 LBA48 user addressable sectors: 488281250 Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 238418 MBytes device size with M = 1000*1000: 25 MBytes (250 GB) cache/buffer size = 8192 KBytes Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, with device specific minimum R/W multiple sector transfer: Max = 16 Current = 8 Recommended acoustic management value: 128, current value: 128 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: *SMART feature set Security Mode feature set *Power Management feature set *Write cache *Look-ahead *Host Protected Area feature set *WRITE_BUFFER command *READ_BUFFER command *NOP cmd *DOWNLOAD_MICROCODE Power-Up In Standby feature set *SET_FEATURES required to spinup after power up SET_MAX security extension *Automatic Acoustic Management feature set *48-bit Address feature set *
Re: avoid redundant block group free-space checks
2011/12/12 Alexandre Oliva ol...@lsd.ic.unicamp.br: It was pointed out to me that the test for enough free space in a block group was wrong in that it would skip a block group that had most of its free space reserved by a cluster. I offer two mutually exclusive, (so far) very lightly tested patches to address this problem. One moves the test to the middle of the clustered allocation logic, between the release of the cluster and the attempt to create a new cluster, with some ugliness due to more indentation, locking operations and testing. The other, that I like better but haven't given any significant amount of testing yet, only performs the test when we fall back to unclustered allocation, relying on btrfs_find_space_cluster to test for enough free space early (it does); it also arranges for the cluster in the current block group to be released before we try unclustered allocation. I've chosen to try the second patch in our ceph environment. It seems that btrfs_find_space_cluster() isn't called any longer. find_free_extent() is much faster now. (I think that the write-io numbers are still to high, though.) Thanks, Christian -- 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: BUG during btrfs device delete missing
On Sat, Dec 10, 2011 at 7:22 PM, Li Zefan l...@cn.fujitsu.com wrote: On Thu, Dec 08, 2011 at 11:06:47AM -0800, David Marcin wrote: raid10 metadata and data filesystem. dmesg log follows. The system is unable to unmount the filesystem after this occurs. Filesystem mounted at/mnt/btrfs with -o compress,degraded Command: btrfs device delete missing /mnt/btrfs [ 283.398222] [ cut here ] [ 283.398289] kernel BUG at /home/apw/COD/linux/fs/btrfs/transaction.c:1329! So this crash means we failed to write all the blocks required to commit the transaction. The reason is that we're getting failed bios to the missing device, and that failure isn't properly eaten by the raid aware endio code. If you pull the top commit from my for-linus branch, it should all work. I know you've got a big FS here, I haven't tested this on raid10 yet, only raid1. If you want to wait a bit for safety I'll do a raid10 run too. The fix looks good to me, and I've tested it on raid10. Thanks Chris and Li. I can confirm that this fixed my issues on raid10 as well. 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: warning and bug on 3.2-rc4 + for-linus from yesterday
Hello!
On Mon, Dec 12, 2011 at 01:30:31AM +0100, David Sterba wrote:
On Fri, Dec 09, 2011 at 12:39:48PM -0800, Simon Kirby wrote:
[ cut here ]
WARNING: at mm/page-writeback.c:1763
__set_page_dirty_nobuffers+0x17b/0x190()
Hardware name: PowerEdge 1950
Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler aoe bnx2
Pid: 14299, comm: btrfs-delalloc- Tainted: GW3.2.0-rc4-hw+ #71
Call Trace:
[810dec2b] ? __set_page_dirty_nobuffers+0x17b/0x190
[8105b050] warn_slowpath_common+0x80/0xc0
[8105b0a5] warn_slowpath_null+0x15/0x20
[810dec2b] __set_page_dirty_nobuffers+0x17b/0x190
[81303b95] compress_file_range+0x535/0x5e0
[811174ee] ? kfree+0xee/0x120
[81303c70] async_cow_start+0x30/0x50
[813220a3] worker_loop+0x173/0x530
[81321f30] ? btrfs_queue_worker+0x310/0x310
[81321f30] ? btrfs_queue_worker+0x310/0x310
[8107c7f6] kthread+0x96/0xb0
[816e09b4] kernel_thread_helper+0x4/0x10
[8107c760] ? kthread_worker_fn+0x190/0x190
[816e09b0] ? gs_change+0x13/0x13
---[ end trace 52453f1ad38744b8 ]---
(several hours later)
1761 if (mapping2) { /* Race with truncate? */
1762 BUG_ON(mapping2 != mapping);
1763 WARN_ON_ONCE(!PagePrivate(page)
!PageUptodate(page));
1764 account_page_dirtied(page, mapping);
1765 radix_tree_tag_set(mapping-page_tree,
1766 page_index(page), PAGECACHE_TAG_DIRTY);
1767 }
The warning pops up just the first time, so I think it may happen more
often, would be interesting to verify this.
We'll try again with s/WARN_ON_ONCE/WARN_ON/ here.
Meanwhile, other problems have come up on this kernel, like a BUG() on
snapshot delete:
[ cut here ]
kernel BUG at fs/btrfs/inode.c:2893!
invalid opcode: [#1] SMP
CPU 1
Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler aoe bnx2
Pid: 20842, comm: btrfsctl Tainted: GW3.2.0-rc4-hw+ #71 Dell Inc.
PowerEdge 1950/0NK937
RIP: 0010:[81304d88] [81304d88]
btrfs_unlink_subvol+0x268/0x270
RSP: 0018:88008eca7d28 EFLAGS: 00010286
RAX: ffe4 RBX: 0c46 RCX: 8800922a2928
RDX: ffe4 RSI: RDI: 8800922a2948
RBP: 88008eca7da8 R08: R09:
R10: R11: 9001 R12: 880075b20548
R13: 88042876aab0 R14: 88026d2f3400 R15: 0100
FS: 7ffc81a2c740() GS:88043fc4() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 7ffc813e8480 CR3: 0002e7a92000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process btrfsctl (pid: 20842, threadinfo 88008eca6000, task
8803d8239630)
Stack:
8802080323f8 88030010 00108eca7d58 8802080323f8
08a0 8803fda1f708 08a0 ff84
00ff 0268 880088788008
Call Trace:
[81323975] btrfs_ioctl_snap_destroy+0x3b5/0x480
[81326ef2] btrfs_ioctl+0x3a2/0x10d0
[816da594] ? do_page_fault+0x254/0x4b0
[8112cdc0] do_vfs_ioctl+0xa0/0x520
[8112d28a] sys_ioctl+0x4a/0x80
[816de8d2] system_call_fastpath+0x16/0x1b
Code: 48 8d 54 92 65 e8 89 f2 00 00 48 8b 5d b9 4c 89 ef e8 4d 2c fd ff 48 89
5d c8 e9 ca fe ff ff 0f 0b eb fe 0f 0b eb fe 0f 1f 40 00 0f 0b eb fe 0f 0b eb
fe 55 48 89 e5 48 83 ec 20 48 89 5d e8 4c
RIP [81304d88] btrfs_unlink_subvol+0x268/0x270
RSP 88008eca7d28
---[ end trace 485334ee1ecd2cc8 ]---
After this, we hit a number of other BUG() and WARN() cases during
mounting on the next boot:
kernel BUG at fs/btrfs/extent-tree.c:6343!
WARNING: at fs/btrfs/extent-tree.c:4754 __btrfs_free_extent+0x627/0x720()
WARNING: at fs/btrfs/extent-tree.c:4801 __btrfs_free_extent+0x6cc/0x720()
kernel BUG at fs/btrfs/extent-tree.c:2287!
I posted them here if they are of any use:
http://0x.ca/sim/ref/3.2-rc4/
We'll probably go back to 2.6.38 again for now, the latest mostly-working
kernel on this box.
Simon-
--
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: Consistent crash with cp reflink on large files
Nik Markovic wrote: Hi All, I have been encountering consistent btrfs filesystem crashes when using cp –reflink=always on a large file and modifying it. I believe that the test file needs to be fairly large as I was not able to reproduce with smaller files. The filesystem size is 45GB and file size is 10GB. It should be fixed in 3.1 by this commit: commit b6f3409b2197e8fcedb43e6600e37b7cfbe0715b Author: Sage Weil s...@newdream.net Date: Tue Sep 20 14:48:51 2011 -0400 Btrfs: reserve sufficient space for ioctl clone Fix a crash/BUG_ON in the clone ioctl due to insufficient reservation. We need to reserve space for: - adjusting the old extent (possibly splitting it) - adding the new extent - updating the inode -- 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: Consistent crash with cp reflink on large files
Nik Markovic wrote: Li Zefan wrote: Nik Markovic wrote: Hi All, I have been encountering consistent btrfs filesystem crashes when using cp –reflink=always on a large file and modifying it. I believe that the test file needs to be fairly large as I was not able to reproduce with smaller files. The filesystem size is 45GB and file size is 10GB. It should be fixed in 3.1 by this commit: commit b6f3409b2197e8fcedb43e6600e37b7cfbe0715b Author: Sage Weil s...@newdream.net Date: Tue Sep 20 14:48:51 2011 -0400 Btrfs: reserve sufficient space for ioctl clone Fix a crash/BUG_ON in the clone ioctl due to insufficient reservation. We need to reserve space for: - adjusting the old extent (possibly splitting it) - adding the new extent - updating the inode Thanks Li, You are probably right. I upgraded to 3.2-rc5 today and was not able to reproduce with 100k iterations. Do you think that applying the same patch to 3.0 should fix this issue in 3.0? yes, it should be fine. -- 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: Consistent crash with cp reflink on large files
Li Zefan wrote: Nik Markovic wrote: Hi All, I have been encountering consistent btrfs filesystem crashes when using cp –reflink=always on a large file and modifying it. I believe that the test file needs to be fairly large as I was not able to reproduce with smaller files. The filesystem size is 45GB and file size is 10GB. It should be fixed in 3.1 by this commit: commit b6f3409b2197e8fcedb43e6600e37b7cfbe0715b Author: Sage Weil s...@newdream.net Date: Tue Sep 20 14:48:51 2011 -0400 Btrfs: reserve sufficient space for ioctl clone Fix a crash/BUG_ON in the clone ioctl due to insufficient reservation. We need to reserve space for: - adjusting the old extent (possibly splitting it) - adding the new extent - updating the inode Thanks Li, You are probably right. I upgraded to 3.2-rc5 today and was not able to reproduce with 100k iterations. Do you think that applying the same patch to 3.0 should fix this issue in 3.0? Nik -- 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
Chunk allocation size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While poking around with btrfs-gui I noticed my fs had a fair number of quite small chunks ( especially metadata ), so I started looking into how they are allocated. It appears that the current rule is to allocate: 1) At most, 10% of the total fs capacity 2) For metadata, at most 256 mb 3) For data, at most 10gb, or 1gb per disk, whichever is lower Why these values? Why have hard coded sizes at all instead of just saying for instance, 4% of total capacity for metadata and 8% of total capacity for data chunks? In my case, I had two 36 gb disks, so this led to data chunks maxing out at 2gb ( or ~2.8% ), and metadata chunks maxing out at 256mb ( or ~0.36% ). It seems to me that ideal chunk sizes should be in the vicinity of 4%-10% of total capacity ( giving a total of 10-21 chunks ), never less than 1% ( giving more than 100 chunks ). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7m1yUACgkQJ4UciIs+XuJ99wCfdhSvFB6S1uz+qTWBJotFoZ0d 6FwAoJuerIp9brqfv1E2PJfRsV7VDEbr =FpRK -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: btrfs encryption problems
What can be done about this? Is there anyone able to reproduce the problem?
On 30/11/2011, 810d4rk 810d...@gmail.com wrote:
I plugged it directly by sata and this is what I get from the 3.1 kernel:
[ 577.850429] ata3: exception Emask 0x10 SAct 0x0 SErr 0x405
action 0xe frozen
[ 577.850433] ata3: irq_stat 0x0040, connection status changed
[ 577.850436] ata3: SError: { PHYRdyChg CommWake DevExch }
[ 577.850443] ata3: hard resetting link
[ 581.768015] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 581.829148] ata3.00: ATA-8: WDC WD7500BPVT-22HXZT1, 01.01A01, max
UDMA/133
[ 581.829151] ata3.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth
31/32), AA
[ 581.833146] ata3.00: configured for UDMA/133
[ 581.848043] ata3: EH complete
[ 581.848134] scsi 2:0:0:0: Direct-Access ATA WDC
WD7500BPVT-2 01.0 PQ: 0 ANSI: 5
[ 581.848250] sd 2:0:0:0: [sdb] 1465149168 512-byte logical blocks:
(750 GB/698 GiB)
[ 581.848253] sd 2:0:0:0: [sdb] 4096-byte physical blocks
[ 581.848300] sd 2:0:0:0: [sdb] Write Protect is off
[ 581.848302] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 581.848323] sd 2:0:0:0: [sdb] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 581.921417] sdb: sdb1
[ 581.921642] sd 2:0:0:0: [sdb] Attached SCSI disk
[ 660.040263] EXT4-fs (dm-4): VFS: Can't find ext4 filesystem
If you plug it in directly with esata, do the IO errors go away? If so,
please post the kernel messages from that.
-chris
--
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 Thu, Dec 1, 2011 at 5:15 AM, 810d4rk 810d...@gmail.com wrote: I plugged it directly by sata and this is what I get from the 3.1 kernel: [ 581.921417] sdb: sdb1 [ 581.921642] sd 2:0:0:0: [sdb] Attached SCSI disk [ 660.040263] EXT4-fs (dm-4): VFS: Can't find ext4 filesystem ... and then what? Did you try decrypting and mounting it? -- Fajar -- 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
