Re: kernel 3.3.4 damages filesystem (?)
I dont know if this is related or not, but I updated two different computers to ubuntu 12, which uses kernel 3.2, and in both I had the same problem: using btrfs with compress-force=lzo, after some IO stress the filesystem became unusable, some sort of busy. Im using kernel 3.0 right now, with no such problem. On 09-05-2012 14:32, Duncan wrote: Helmut Hullen posted on Mon, 07 May 2012 12:46:00 +0200 as excerpted: The 3 btrfs disks are connected via a SiI 3114 SATA-PCI-Controller. Only 1 of the 3 disks seems to be damaged. I don't plan to rehash the raid0/single discussion here, but here's some perhaps useful additional information on that hardware: For some years I've been running that same hardware, SiI 3114 SATA PCI, on an old dual-socket 3-digit Opteron system, running for some years now dual dual-core Opteron 290s (the highest they went, 2.8 GHz, 4 cores in two sockets). However, I *WAS* running them in RAID-1, 4-disk md RAID-1, to be exact (with reiserfs, FWIW). What's VERY interesting is that I've just returned from being offline for several days due to severe disk-I/O hardware issues of my own -- again, on that Sil-SATA 3114. Most of the time I was getting full system crashes, but perhaps 25-33% of the time it didn't fully crash the system, simply error out with an eventual ATA reset. When the system didn't crash immediately, most of the time (about 80% I'd say) the reset would be good and I'd be back up, but sometimes it'd repeatedly reset, occasionally not ever becoming usable again. As the drives are all the same quite old Seagate 300 gig drives, at about half their rated SMART operating hours but I think well beyond the 5 year warrantee, I originally thought I'd just learned my lesson on the don't use all the same model or you're risking them all going out at once rule, but I bought a new drive (half-TB seagate 2.5" drive, I've been thinking about going 2.5" for awhile now and this was the chance, I'll RAID it later with at least one more, preferably a different run at least if not a different model) and have been SLOWLY, PAINFULLY, RESETTINGLY copying stuff over from one or another of the four RAID-1 drives. The reset problem, however, hasn't gone away, tho it's rather reduced on the newer hardware. I also happened to have a 4-3.5-in-3-5.25-slot drive enclosure that seemed to be making the problem worse, as when I first tried the new 2.5 inch retrofitted into it, the reset problem was as bad with it as with the old drives, but when I ran it "lose", just cabled into the mobo and power-supply directly, resets went down significantly but did NOT go away. So... I've now concluded that I need a new controller and will probably buy one in a day or two. Meanwhile, I THOUGHT it was "just me" with the SIL-SATA controller, until I happened to see the same hardware mentioned on this thread. Now, I'm beginning to suspect that there's some new kernel DMA or storage or perhaps xorg/mesa (AMD AGPGART, after all, handling the DMA using half the aperture. if either the graphics or storage try writing to the wrong half...) problem that stressed what was already aging hardware, triggering the problem. It's worth noting that I tried running an older kernel and rebuilding (on Gentoo) most of X/mesa/anything-else-I-could- think-might-be-related between older versions that WERE working find before and newer versions, and reverting to older didn't help, so it's apparently NOT a direct software-only-bug. However, what I'm wondering now is whether as I said, software upgrades added stress to already aging hardware, such that it tipped it over the edge, and by the time I tried reverting, I'd already had enough crashes and etc that my entire system was unstable, and reverting to older software didn't help because now the hardware was unstable as well. I'd still chalk it up to simply failing hardware, except that it's a rather interesting coincidence that both you and I had their SIL-SATA 3114s go bad at very close to the same time. Meanwhile, I did recently see an interesting kernel commit, either late 3.4-rc5+ or early 3.4-rc6+. I don't want to try to track it down and lose this post to a crash on a less than stable system, but it did mention that AMD AGPGARTs sometimes poked holes in memory allocations and the commit was to try to allow for that. I'm not sure how long the bad code had been in the kernel, but if it was introduced at say the 3.2 or 3.3 kernel, it could be that is what first started triggering the lockups that lead to more and more system instability, until now I've bought a new drive and it looks like I'm going to need to replace the onboard SIL- SATA. So, some questions: * Do you run OpenGL/Mesa at all on that system, possibly with an OpenGL compositing window manager? * If so, how new is your mesa and xorg-server, and what is your video card/driver? * Do you run quite new kernels, say 3.3/3.4? * What libffi and cairo? (I did notice reverting libffi seemed to lessen th
Re: Can btrfs silently repair read-error in raid1
On 08-05-2012 18:47, Hubert Kario wrote: On Tuesday 08 of May 2012 04:45:51 cwillu wrote: On Tue, May 8, 2012 at 1:36 AM, Fajar A. Nugraha wrote: On Tue, May 8, 2012 at 2:13 PM, Clemens Eisserer wrote: Hi, I have a quite unreliable SSD here which develops some bad blocks from time to time which result in read-errors. Once the block is written to again, its remapped internally and everything is fine again for that block. Would it be possible to create 2 btrfs partitions on that drive and use it in RAID1 - with btrfs silently repairing read-errors when they occur? Would it require special settings, to not fallback to read-only mode when a read-error occurs? The problem would be how the SSD (and linux) behaves when it encounters bad blocks (not bad disks, which is easier). If it does "oh, I can't read this block. I just return an error immediately", then it's good. However, in most situation, it would be like "hmmm, I can't read this block, let me retry that again. What? still error? then lets retry it again, and again.", which could take several minutes for a single bad block. And during that time linux (the kernel) would do something like "hey, the disk is not responding. Why don't we try some stuff? Let's try resetting the link. If it doesn't work, try downgrading the link speed". In short, if you KNOW the SSD is already showing signs of bad blocks, better just throw it away. The excessive number of retries (basically, the kernel repeating the work the drive already attempted) is being addressed in the block layer. "[PATCH] libata-eh don't waste time retrying media errors (v3)", I believe this is queued for 3.5 I just hope they don't remove retries completely, I've seen the second or third try return correct data on multiple disks from different vendors. (Which allowed me to use dd to write the data back to force relocation) But yes, Linux is a bit too overzelous with regards to retries... Regards, I hope they do. If you wish, you can force the retry, just trying your command again. This decision should happen in a higher level. -- 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
failed to read tree root
I'm having a 'failed to read tree root' message when trying to mount a disk which was mounting fine earlier. Is there any hope to get the data back? Atila Sep 1 14:15:33 gentoo-atila [940695.233191] Btrfs loaded Sep 1 14:15:33 gentoo-atila [940695.244360] device fsid 5341dc082e28ff71-ba2fe914734b3884 devid 1 transid 16533 /dev/sdh1 Sep 1 14:15:33 gentoo-atila [940695.244901] btrfs: setting nodatasum Sep 1 14:15:33 gentoo-atila [940695.253742] btrfs bad tree block start 12241455839323779053 406978957312 Sep 1 14:15:33 gentoo-atila [940695.254241] btrfs bad tree block start 12241455839323779053 406978957312 Sep 1 14:15:33 gentoo-atila [940695.254741] btrfs bad tree block start 5557049029311685575 406978957312 Sep 1 14:15:33 gentoo-atila [940695.254744] btrfs: failed to read tree root on sdh1 Sep 1 14:15:33 gentoo-atila [940695.255140] btrfs: open_ctree failed -- 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]Re: The first character disappears
Should be rstrip instead of strip.
Atila
Signed-off-by: Atila
---
bcp |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/bcp b/bcp
index 5729e91..7c6b351 100755
--- a/bcp
+++ b/bcp
@@ -107,7 +107,7 @@ if src_args > 1:
exit(1)
for srci in xrange(0, src_args):
-src = args[srci]
+src = args[srci].rstrip('/')
if os.path.isfile(src):
statinfo = os.lstat(src)
force_name = None
@@ -136,7 +136,7 @@ for srci in xrange(0, src_args):
srcname = os.path.join(dirpath, x)
statinfo = os.lstat(srcname)
-if srcname.startswith(src):
+if srcname.startswith(src + '/'):
part = srcname[len(src) + 1:]
if stat.S_ISLNK(statinfo.st_mode):
@@ -152,7 +152,7 @@ for srci in xrange(0, src_args):
for f in filenames:
srcname = os.path.join(dirpath, f)
-if srcname.startswith(src):
+if srcname.startswith(src + '/'):
part = srcname[len(src) + 1:]
statinfo = os.lstat(srcname)
--
1.6.4
*
--
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]Re: The first character disappears
*
Signed-off-by: Atila
---
bcp |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/bcp b/bcp
index 5729e91..7c6b351 100755
--- a/bcp
+++ b/bcp
@@ -107,7 +107,7 @@ if src_args > 1:
exit(1)
for srci in xrange(0, src_args):
-src = args[srci]
+src = args[srci].strip('/')
if os.path.isfile(src):
statinfo = os.lstat(src)
force_name = None
@@ -136,7 +136,7 @@ for srci in xrange(0, src_args):
srcname = os.path.join(dirpath, x)
statinfo = os.lstat(srcname)
-if srcname.startswith(src):
+if srcname.startswith(src + '/'):
part = srcname[len(src) + 1:]
if stat.S_ISLNK(statinfo.st_mode):
@@ -152,7 +152,7 @@ for srci in xrange(0, src_args):
for f in filenames:
srcname = os.path.join(dirpath, f)
-if srcname.startswith(src):
+if srcname.startswith(src + '/'):
part = srcname[len(src) + 1:]
statinfo = os.lstat(srcname)
--
1.6.4
*
--
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
Compression of large files
During a file write, if the compression doesn't proves to be economical to a portion of the file, the whole file is marked as nocompress, and subsequent writes don't use compression at all. This can be seen as a feature, as it saves CPU in files like videos. But if the file is a dd image of a disk, or other types of large files, this behavior is undesirable, since different portions of the file will have different compression ratios. I only became aware of this after searching the source code, after spending some hours trying to find out why the compression wasn't working. This can be a really unexpected behavior for a end user who is looking for compression. The specific part of the code is at inode.c: 477 <#l477> /* flag the file so we don't compress in the future */ 478 <#l478> btrfs_set_flag(inode, NOCOMPRESS); How about commenting line 478? Atila -- 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
