On Mon, Jan 13, 2014 at 05:40:33PM -0700, Chris Murphy wrote:
I see no obvious hardware source for the problem, SATA Phy Event Counters are
zeros except a few COMRESET events which is pretty minor. No ICRC or UDMA-CRC
errors recorded. No reallocated or pending bad sectors.
I'd look at your
Duncan 1i5t5.duncan at cox.net writes:
[...]
Normally you'd do a data balance to consolidate data in the data chunks
and return the now freed chunks to the unallocated space pool, but you're
going to have problems doing that ATM, for two reasons. The likely
easiest to work around is that
Chris Murphy posted on Mon, 13 Jan 2014 09:46:08 -0700 as excerpted:
On Jan 13, 2014, at 1:18 AM, Duncan 1i5t5.dun...@cox.net wrote:
I use GPT partitioning (instead of MBR) for better fault tolerance and
flexibility here, too,
Off topic but related to above, you might find it vaguely
Chris Murphy posted on Tue, 14 Jan 2014 00:49:13 -0700 as excerpted:
On Jan 13, 2014, at 11:03 PM, Duncan 1i5t5.dun...@cox.net wrote:
Chris Murphy posted on Mon, 13 Jan 2014 17:40:33 -0700 as excerpted:
btrfs-image -c 9-t 4 /dev/sdX /mnt/pathtoanothervolume+filename
You can keep it
On Tue, Jan 14, 2014 at 09:30:14AM +, Duncan wrote:
Chris Murphy posted on Tue, 14 Jan 2014 00:49:13 -0700 as excerpted:
On Jan 13, 2014, at 11:03 PM, Duncan 1i5t5.dun...@cox.net wrote:
Chris Murphy posted on Mon, 13 Jan 2014 17:40:33 -0700 as excerpted:
btrfs-image -c 9-t 4
btrfs filesystem show not-found-label should return non zero
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-filesystem.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index c50a65f..ee6cc84 100644
---
since now handle_print()-print_one_fs() calls add_seen_fsid()
the thread has to go through free_seen_fsid()
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-filesystem.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
Hi Wang,
I agree we use transid to find most proper device, but this check is not
right.
Here @found_transid is the most biggest generation, so a right candidate
device's
transid should be @found_tranid -1 (power off for example)or same as
@found_transid.
Anyway, i think the right way should
Steps to reproduce:
# mkfs.btrfs -f /dev/sda8
# mount /dev/sda8 /mnt -o flushoncommit
# dd if=/dev/zero of=/mnt/data bs=4k count=102400
# mount /dev/sda8 /mnt -o remount, ro
When remounting RW to RO, the logic is to firstly set flag
to RO and then commit transaction, however with option
On 01/14/2014 02:40 AM, David Sterba wrote:
On Wed, Jan 08, 2014 at 11:09:02PM +0800, Wang Shilong wrote:
Hello David,
On Tue, Jan 07, 2014 at 05:25:18PM +0800, Wang Shilong wrote:
Steps to reproduce:
# mkfs.btrfs -f /dev/sda8
# mount /dev/sda8 /mnt
# btrfs sub snapshot -r /mnt /mnt/snap1
#
btrfs_read_fs_root_no_name() will check its root refs, and will
return us ENOENT if this root in deletion.
However, in some case, for example qgroup, we still need to track
those roots, fix it.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
fs/btrfs/backref.c | 2 +-
1 file changed,
On Mon, Jan 13, 2014 at 02:03:52PM -0500, Jim Salter wrote:
OK, thanks. If kernel memory fragmentation is a big factor, that would also
explain why it succeeds after a reboot but does not succeed after weeks of
uptime...
Yes, that's it.
--
To unsubscribe from this list: send the line
We met the performance fluctuating problem when we synchronized the file data.
The main reason of this problem was that we might only flush part dirty pages
in a ordered extent, then got that ordered extent, wait for the csum
calcucation. But if no task flushed the left part, we would wait until
The performance of fsync dropped down suddenly sometimes, the main reason
of this problem was that we might only flush part dirty pages in a ordered
extent, then got that ordered extent, wait for the csum calcucation. But if
no task flushed the left part, we would wait until the flusher flushed
We are sure that:
- one ordered extent just has one csum calculation worker, and no one
access the csum list during the csum calculation except the worker.
- we don't change the list and free the csum until no one reference
to the ordered extent
So it is safe to add csum without the lock.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/ordered-data.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
index 69582d5..e4c3d56 100644
--- a/fs/btrfs/ordered-data.c
+++ b/fs/btrfs/ordered-data.c
@@ -433,6
There was a problem in the old code:
If we failed to log the csum, we would free all the ordered extents in the log
list
including those ordered extents that were logged successfully, it would make the
log committer not to wait for the completion of the ordered extents.
This patch doesn't insert
Dear developers,
I have a 1250MHZ 512MB RAM x86 UP system. It contains several btrfs
partitions on top of LVM mounted with compress=lzo,space_cache,noatime
and some other standard options.
It uses a trimmed custom kernel. The -dirty part in it's name is
because the command 'hostname' was not
FWIW, for those following along: took the system down for a reboot last
night at 9PM EST, then tried the full send after the reboot - took 12
hours or so to complete, but completed no issues, as have a few
incremental sends since.
So, yeah, definitely looks related to kernel memory
On Thu, Jan 09, 2014 at 02:52:27PM +, Chris Mason wrote:
You may need to upgrade the kernel to get new features offered by a
new userspace, but I think we should absolutely not be changing
userspace in a way that makes it incompatible with older kernels.
I'd really prefer that we
On Wed, Jan 08, 2014 at 01:50:58PM -0800, Timothy Pepper wrote:
The patch below is a simple quick attempt at allowing the filesystem
UUID to be specified by the user at mkfs time.
There was a similar patch some time ago, that also added it to convert:
From: Wang Shilong wangsl.f...@cn.fujitsu.com
Now we have kicked off transaction from btrfs send, it is not safe
that we use extent commit root to search.
I happended to catch this problem when running sending and snapshot
in my desktop.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
From: Wang Shilong wangsl.f...@cn.fujitsu.com
To search tree root without transaction protection, we should neither search
commit
root nor skip locking here, fix it.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
fs/btrfs/send.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Mon, Jan 13, 2014 at 09:14:55PM +0800, Anand Jain wrote:
From: Anand Jain anand.j...@oracle.com
this patch will make btrfsck operations to open disk in exclusive mode,
so that mount will fail when btrfsck is running
Makes sense, especially if fsck is in the repair mode, mounting such fs
On Jan 14, 2014, at 2:30 AM, Duncan 1i5t5.dun...@cox.net wrote:
I wonder if it compresses?
-c 9 is max compression although I don't know what algorithm btrfs-image uses
off hand. If I use xz on it, 193MB becomes 192MB.
Chris Murphy
--
To unsubscribe from this list: send the line
On Mon, Dec 30, 2013 at 04:12:55PM +0800, Liu Bo wrote:
--- a/ctree.h
+++ b/ctree.h
@@ -470,6 +470,7 @@ struct btrfs_super_block {
#define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF (1ULL 6)
#define BTRFS_FEATURE_INCOMPAT_RAID56(1ULL 7)
#define
On Jan 9, 2014, at 6:31 PM, George Mitchell geo...@chinilu.com wrote:
Jim, my point was that IF the drive does not successfully resolve the bad
block issue and btrfs takes a write failure every time it attempts to
overwrite the bad data, it is not going to remap that data, but rather it is
On Tue, 14 Jan 2014 12:13:09 -0700
Chris Murphy li...@colorremedies.com wrote:
On Jan 9, 2014, at 6:31 PM, George Mitchell geo...@chinilu.com wrote:
Jim, my point was that IF the drive does not successfully resolve the bad
block issue and btrfs takes a write failure every time it
I have a btrfs volume with two disks in it. Inspired by the recent LWN
series on btrfs, I set it up last week and things seemed to be going
quite well. However, I tried to balance the disks the other day since
they were quite out-of-balance, but the balance job failed to complete,
error'ing out
On 01/14/2014 11:13 AM, Chris Murphy wrote:
On Jan 9, 2014, at 6:31 PM, George Mitchell geo...@chinilu.com wrote:
Jim, my point was that IF the drive does not successfully resolve the bad block
issue and btrfs takes a write failure every time it attempts to overwrite the
bad data, it is not
Hi,
I'd like to have a recent btrfs kernel implementation on my android phone.
Unfortunately, I've only kernel sources like 3.0.64 for the phone
(cyanogenmod rom for samsung galaxy note 2).
Is there a chance to get the recent btrfs implementation backported to
a 3.0 kernel?
best
--
Dr.
On Tue, 14 Jan 2014 12:29:28 -0800
George Mitchell geo...@chinilu.com wrote:
what we are lacking at this point is a SMART capability to provide
visual notifications to the user when any hard drive starts to seriously
degrade or suddenly fails.
You can configure smartd (from smartmontools)
On Jan 14, 2014, at 12:37 PM, Roman Mamedov r...@romanrm.net wrote:
I vaguely remember having some drives that were not able to remap a single
block on write, but doing that successfully if I overwrote a sizable area
around (and including) that block, or overwrite the whole drive. And after
On Wed, Jan 15, 2014 at 03:00:21AM +0600, Roman Mamedov wrote:
That said, do not fall into a false sense of security relying on proprietary,
barely if ever updated after the device has been shipped, and often very
peculiar-behaving SMART routines inside the black-box HDD firmware as your
most
On Jan 14, 2014, at 1:29 PM, George Mitchell geo...@chinilu.com wrote:
Chris, Please don't misunderstand me. I am not advocating that btrfs or any
other filesystem should be dealing with bad blocks. I believe very strongly
that if the drive firmware can't deal with that transparently
On Tue, 14 Jan 2014 14:05:11 -0700
Chris Murphy li...@colorremedies.com wrote:
On Jan 14, 2014, at 12:37 PM, Roman Mamedov r...@romanrm.net wrote:
I vaguely remember having some drives that were not able to remap a single
block on write, but doing that successfully if I overwrote a
On Jan 14, 2014, at 2:06 PM, Hugo Mills h...@carfax.org.uk wrote:
On Wed, Jan 15, 2014 at 03:00:21AM +0600, Roman Mamedov wrote:
That said, do not fall into a false sense of security relying on proprietary,
barely if ever updated after the device has been shipped, and often very
On 01/14/2014 01:00 PM, Roman Mamedov wrote:
On Tue, 14 Jan 2014 12:29:28 -0800
George Mitchell geo...@chinilu.com wrote:
what we are lacking at this point is a SMART capability to provide
visual notifications to the user when any hard drive starts to seriously
degrade or suddenly fails.
You
On 01/14/2014 01:00 PM, Roman Mamedov wrote:
On Tue, 14 Jan 2014 12:29:28 -0800
George Mitchell geo...@chinilu.com wrote:
what we are lacking at this point is a SMART capability to provide
visual notifications to the user when any hard drive starts to seriously
degrade or suddenly fails.
You
On Jan 14, 2014, at 2:19 PM, Roman Mamedov r...@romanrm.net wrote:
On Tue, 14 Jan 2014 14:05:11 -0700
Chris Murphy li...@colorremedies.com wrote:
On Jan 14, 2014, at 12:37 PM, Roman Mamedov r...@romanrm.net wrote:
I vaguely remember having some drives that were not able to remap a
This patch removes the word `to' from the `Can't access to X' error
messages.
Mitchel Humpherys (1):
btrfs-progs: fix minor grammar issues
cmds-balance.c| 10 +-
cmds-device.c | 4 ++--
cmds-filesystem.c | 6 +++---
cmds-scrub.c | 2 +-
cmds-subvolume.c | 10
Remove the extraneous `to' from `Can't access to X'.
Signed-off-by: Mitchel Humpherys mitch.spec...@gmail.com
---
cmds-balance.c| 10 +-
cmds-device.c | 4 ++--
cmds-filesystem.c | 6 +++---
cmds-scrub.c | 2 +-
cmds-subvolume.c | 10 +-
5 files changed, 16
On Jan 14, 2014, at 2:37 PM, Chris Murphy li...@colorremedies.com wrote:
I've seen that happen on OS X Server (client doesn't produce SMART warnings
in user space).
Oops. It does, just not automatically, it seems you have to go look for this in
Disk Utility.
Chris Murphy
--
To unsubscribe
On 01/14/2014 01:14 PM, Chris Murphy wrote:
On Jan 14, 2014, at 1:29 PM, George Mitchell geo...@chinilu.com wrote:
And the key to monitoring hard drive health, in my opinion, is SMART and what
we are lacking at this point is a SMART capability to provide visual
notifications to the user when
On Tue, Jan 14, 2014 at 01:44:02PM -0800, Mitchel Humpherys wrote:
This patch removes the word `to' from the `Can't access to X' error
messages.
Thanks. That's been annoying me intermittently for years. (Just not
quite enough to do anything about it).
Hugo.
Mitchel Humpherys (1):
On 01/14/2014 01:14 PM, Chris Murphy wrote:
On Jan 14, 2014, at 1:29 PM, George Mitchell geo...@chinilu.com wrote:
And the key to monitoring hard drive health, in my opinion, is SMART and what
we are lacking at this point is a SMART capability to provide visual
notifications to the user when
On Tue, 14 Jan 2014 14:37:46 -0700
Chris Murphy li...@colorremedies.com wrote:
Reserve sectors are fundamental to ECC. If there are no more reserves, the
status should be a failed drive, it can no longer do its own relocation of
data experiencing transient read errors in this case.
With the
On 01/14/2014 01:14 PM, Chris Murphy wrote:
And the key to monitoring hard drive health, in my opinion, is SMART and what
we are lacking at this point is a SMART capability to provide visual
notifications to the user when any hard drive starts to seriously degrade or
suddenly fails.
Gnome
On Tue, Jan 14 2014 at 11:47:18 AM, Mitchel Humpherys mitch.spec...@gmail.com
wrote:
Other possibly relevant information:
$ sudo btrfs filesystem show /local
Label: none uuid: 03a83a42-0bc7-42a2-bed6-df19c825897c
Total devices 2 FS bytes used 380.83GiB
On Tue 14 Jan at 17:06:29 +0100 dste...@suse.cz said:
On Wed, Jan 08, 2014 at 01:50:58PM -0800, Timothy Pepper wrote:
The patch below is a simple quick attempt at allowing the filesystem
UUID to be specified by the user at mkfs time.
There was a similar patch some time ago, that also added
On tue, 14 Jan 2014 16:40:28 -0800, Timothy Pepper wrote:
On Tue 14 Jan at 17:06:29 +0100 dste...@suse.cz said:
On Wed, Jan 08, 2014 at 01:50:58PM -0800, Timothy Pepper wrote:
The patch below is a simple quick attempt at allowing the filesystem
UUID to be specified by the user at mkfs time.
On Tue, Jan 14, 2014 at 06:34:19PM +0100, David Sterba wrote:
On Mon, Dec 30, 2013 at 04:12:55PM +0800, Liu Bo wrote:
--- a/ctree.h
+++ b/ctree.h
@@ -470,6 +470,7 @@ struct btrfs_super_block {
#define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF (1ULL 6)
#define
this patch will make the btrfsck and btrfsck --repair
to work in exclusive mode, by opening the device
with the O_EXCL flag
Signed-off-by: Anand Jain anand.j...@oracle.com
---
v2: renamed OPEN_CTREE_O_EXCL to OPEN_CTREE_EXCLUSIVE, thanks David
cmds-check.c | 3 ++-
disk-io.c| 10
My late client made his last will and testament in your favour, i sent
letters to you but got no response, i advise you contact me
immediately.
Barr Mark Freedman
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
+linux-btrfs@vger.kernel.org
I am not sure if
# btrfs-image -c9 -t4 /dev/sda5 /some/path
parent transid verify failed on 602529792 wanted 23460 found 23463
parent transid verify failed on 602529792 wanted 23460 found 23463
parent transid verify failed on 602529792 wanted 23460 found 23463
parent
55 matches
Mail list logo
