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
Duncan <1i5t5.duncan 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 th
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 va
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/
>>>
>>> You can keep it handy in case a
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-i
btrfs filesystem show should return non zero
Signed-off-by: Anand Jain
---
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
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@
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
---
cmds-filesystem.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index ee6cc84..d38fae6 1
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 b
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
flus
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
# b
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
---
fs/btrfs/backref.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
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 "unsubs
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 th
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 the
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.
Sign
Signed-off-by: Miao Xie
---
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 +433,8 @@ void btrfs_
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 ther
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 fragmentati
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 th
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:
http://www.spinics.net/lists/linux-btrfs/m
From: Wang Shilong
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
---
Changelog v1->v2:
extent_from_logical() als
From: Wang Shilong
To search tree root without transaction protection, we should neither search
commit
root nor skip locking here, fix it.
Signed-off-by: Wang Shilong
---
fs/btrfs/send.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
inde
On Mon, Jan 13, 2014 at 09:14:55PM +0800, Anand Jain wrote:
> From: Anand Jain
>
> 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
would be bad.
> --
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 "unsub
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 BTRFS_FEATURE_INCOMPAT_
On Jan 9, 2014, at 6:31 PM, George Mitchell 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
> going to f
On Tue, 14 Jan 2014 12:13:09 -0700
Chris Murphy wrote:
>
> On Jan 9, 2014, at 6:31 PM, George Mitchell 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 dat
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 wit
On 01/14/2014 11:13 AM, Chris Murphy wrote:
On Jan 9, 2014, at 6:31 PM, George Mitchell 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
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. Johannes
On Tue, 14 Jan 2014 12:29:28 -0800
George Mitchell 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) to send you E-Mai
On Jan 14, 2014, at 12:37 PM, Roman Mamedov 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
> that they w
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
> mo
On Jan 14, 2014, at 1:29 PM, George Mitchell 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 the drive is,
>
On Tue, 14 Jan 2014 14:05:11 -0700
Chris Murphy wrote:
>
> On Jan 14, 2014, at 12:37 PM, Roman Mamedov 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 includi
On Jan 14, 2014, at 2:06 PM, Hugo Mills 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
>> peculiar-behaving SMART
On 01/14/2014 01:00 PM, Roman Mamedov wrote:
On Tue, 14 Jan 2014 12:29:28 -0800
George Mitchell 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 smart
On 01/14/2014 01:00 PM, Roman Mamedov wrote:
On Tue, 14 Jan 2014 12:29:28 -0800
George Mitchell 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 smart
On Jan 14, 2014, at 2:19 PM, Roman Mamedov wrote:
> On Tue, 14 Jan 2014 14:05:11 -0700
> Chris Murphy wrote:
>
>>
>> On Jan 14, 2014, at 12:37 PM, Roman Mamedov wrote:
>>>
>>> I vaguely remember having some drives that were not able to remap a single
>>> block on write, but doing that succe
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
---
cmds-balance.c| 10 +-
cmds-device.c | 4 ++--
cmds-filesystem.c | 6 +++---
cmds-scrub.c | 2 +-
cmds-subvolume.c | 10 +-
5 files changed, 16 insertions(+), 16 deletions(-
On Jan 14, 2014, at 2:37 PM, Chris Murphy 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 from this list: send
On 01/14/2014 01:14 PM, Chris Murphy wrote:
On Jan 14, 2014, at 1:29 PM, George Mitchell 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 star
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 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 star
On Tue, 14 Jan 2014 14:37:46 -0700
Chris Murphy 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 Reallocated sector cou
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 d
On Tue, Jan 14 2014 at 11:47:18 AM, Mitchel Humpherys
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
> devid1 size 410.1
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
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.
Th
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 BTRFS_FEATU
On Jan 14, 2014, at 4:24 PM, Holger Brandsmeier wrote:
> Dear Chris,
>
> as requested:
>
> # btrfs fi show
> Label: none uuid: 267f069c-11da-4d2a-88fa-00cab4e28149
>Total devices 1 FS bytes used 12.68GiB
>devid1 size 29.82GiB used 24.27GiB path /dev/sdb1
> Label: none uui
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
---
v2: renamed OPEN_CTREE_O_EXCL to OPEN_CTREE_EXCLUSIVE, thanks David
cmds-check.c | 3 ++-
disk-io.c| 10 --
disk-io.h| 1 +
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 ma
+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
56 matches
Mail list logo
