Duncan 1i5t5.dun...@cox.net schrieb:
While in theory btrfs has the device= mount option, and the kernel has
rootflags= to tell it what mount options to use, at least last I checked
a few kernel cycles ago (I'd say last summer, so 3-5 kernel cycles ago),
for some reason rootflags=device=
Long story short.. Ive been having problems with random files getting
uncorrectable CRC errors on a 23TB filesystem.. RAID6 on an LSI card.
Replaced all SAS cables, replaced single drives at a time, replaced
controller card.
Finally came to the conclusion that something must be corrupt in the
On Fri, Feb 13, 2015 at 12:47:54PM +, Filipe Manana wrote:
This test is motivated by an fsync issue discovered in btrfs.
The issue was that we could lose file data, that was previously fsync'ed
successfully, if we end up shrinking (via truncate) the file, add a hard
link to our file and
On Sun, Feb 15, 2015 at 5:06 PM, Tim DeNike t...@denike.us wrote:
Long story short.. Ive been having problems with random files getting
uncorrectable CRC errors on a 23TB filesystem.. RAID6 on an LSI card.
Replaced all SAS cables, replaced single drives at a time, replaced
controller card.
Just like label change, use sb_want_write() to do a correct protection.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
v4:
Newly introduced.
v5:
Change to sb_want_write().
v6:
Move sb_want_write() to the beginning of the function.
v7:
None
v8:
Move sb_want_write() after get
Hi,
After running `btrfs check --init-csum-tree` 3.18.2 and 3.19-rc2 on a
btrfs all checksums are gone (thousands of line in the form of `no csum
found for inode X start Y` in `/var/log/kern.log`). I know that this
behavior (to delete all csums) was a stub in a dev version and remember
that it was
On Sun, Feb 15, 2015 at 4:39 AM, Liu Bo bo.li@oracle.com wrote:
On Fri, Feb 13, 2015 at 04:56:14PM +, Filipe Manana wrote:
If we are recording in the tree log that an inode has new names (new hard
links were added), we would drop items, belonging to the inode, that we
shouldn't:
1)
When punching a file hole if we endup only zeroing parts of a page,
because the start offset isn't a multiple of the sector size or the
start offset and length fall within the same page, we were not updating
the inode item. This prevented an fsync from doing anything, if no other
file changes
This test is motivated by an fsync issue discovered in btrfs.
The issue was that after punching a hole for a small range, which
affected only a partial page, an fsync operation would have no effect
at all. This was because for this particular case the btrfs hole
punching implementation did not
Here's a new one (with kernel 3.18.7++):
$btrfs --version
Btrfs v3.18.2 (also tried 3.19-rc2)
$mount /dev/sdf1 /mnt/usb
$btrfs filesystem df /mnt/usb
Data, single: total=8.00MiB, used=256.00KiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=1.00GiB, used=112.00KiB
OK, I see. Maybe there is even more damaged...
Now I finished my second backup of the important data and just
killed this damaged raid. I created a new one and now I am restoring
my data. Let's hope it will last longer this time :)
Regards,
Tobias
2015-02-15 4:30 GMT+01:00 Liu Bo
On Sun, Feb 15, 2015 at 5:06 PM, Tim DeNike t...@denike.us wrote:
Long story short.. Ive been having problems with random files getting
uncorrectable CRC errors on a 23TB filesystem.. RAID6 on an LSI card.
This is LSI hardware RAID6? Or Btrfs raid6 with an LSI HBA? If you can
still mount -o ro,
I had a failed drive in RAID-1, so it was replaced with a good one,
followed by:
btrfs device add /dev/sdb4 /home
btrfs device delete missing /home
4 days later, it got to a state when there is no IO anymore (according
to iostat), btrfs device delete missing did not complete:
# uptime
On Sun, Feb 15, 2015 at 7:07 PM, Tim DeNike t...@denike.us wrote:
LSI hardware raid6.
Is metadata profile DUP or single?
I could mount the volume and read/write to it but
larger files (10+GB) would often Immediately have u correctable CRC
errors if I did a scrub right after they were
From: Zhao Lei zhao...@cn.fujitsu.com
for() is obviously better in these code block, and remove noused
init-value to reduce about 6 bytes binary size.
Reviewed-by: David Sterba dste...@suse.cz
Signed-off-by: Zhao Lei zhao...@cn.fujitsu.com
---
fs/btrfs/volumes.c | 9 +++--
1 file changed, 3
From: Zhao Lei zhao...@cn.fujitsu.com
1: Remove unused DEFINE_WAIT(wait)
2: Use a look instead of goto
Changelog v1-v2:
Remove likely() in v1 because it is not a performance sensitive path,
suggesed by: David Sterba dste...@suse.cz
Acked-by: David Sterba dste...@suse.cz
Signed-off-by: Zhao
From: Zhao Lei zhao...@cn.fujitsu.com
wait_event() is just suit for these hand-made code.
Reviewed-by: David Sterba dste...@suse.cz
Signed-off-by: Zhao Lei zhao...@cn.fujitsu.com
---
fs/btrfs/dev-replace.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git
From: Zhao Lei zhao...@cn.fujitsu.com
for() is obviously better in these code block, and remove noused
init-value to reduce about 6 bytes binary size.
Reviewed-by: David Sterba dste...@suse.cz
Signed-off-by: Zhao Lei zhao...@cn.fujitsu.com
---
fs/btrfs/volumes.c | 9 +++--
1 file changed, 3
From: Zhao Lei zhao...@cn.fujitsu.com
1: Remove unused DEFINE_WAIT(wait)
2: Use a loop instead of goto
Changelog v2-v3:
s/look/loop in description.
Changelog v1-v2:
Remove likely() in v1 because it is not a performance sensitive path,
suggesed by: David Sterba dste...@suse.cz
Acked-by:
From: Zhao Lei zhao...@cn.fujitsu.com
wait_event() is just suit for these hand-made code.
Reviewed-by: David Sterba dste...@suse.cz
Signed-off-by: Zhao Lei zhao...@cn.fujitsu.com
---
fs/btrfs/dev-replace.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git
On Sun, Feb 15, 2015 at 1:50 AM, Karl-Philipp Richter
rich...@richtercloud.de wrote:
Hi,
After running `btrfs check --init-csum-tree` 3.18.2 and 3.19-rc2 on a
btrfs all checksums are gone (thousands of line in the form of `no csum
found for inode X start Y` in `/var/log/kern.log`). I know that
On Sun, Feb 15, 2015 at 10:38:54PM +, Filipe Manana wrote:
When punching a file hole if we endup only zeroing parts of a page,
because the start offset isn't a multiple of the sector size or the
start offset and length fall within the same page, we were not updating
the inode item. This
On Mon, Feb 16, 2015 at 11:33:37AM +1100, Dave Chinner wrote:
On Fri, Feb 13, 2015 at 12:47:54PM +, Filipe Manana wrote:
This test is motivated by an fsync issue discovered in btrfs.
The issue was that we could lose file data, that was previously fsync'ed
successfully, if we end up
Kai Krakow posted on Sun, 15 Feb 2015 12:11:56 +0100 as excerpted:
Duncan 1i5t5.dun...@cox.net schrieb:
Gentoo here, too. And I tried to fiddle around with the exact same issue
some kernel versions back and didn't get it to work, so I did go with
dracut which works pretty well for me -
On Sat, Feb 14, 2015 at 11:28 PM, Duncan 1i5t5.dun...@cox.net wrote:
Chris Murphy posted on Sat, 14 Feb 2015 04:52:12 -0700 as excerpted:
Also, there's a nasty
little gotcha, there is no equivalent for mdadm bitmap. So once one
member drive is mounted degraded+rw, it's changed, and there's no
25 matches
Mail list logo
