On Mon, Aug 25, 2014 at 02:26:49PM +0900, Naohiro Aota wrote:
Hi, list
I'm having trouble with my btrfs FS recently and running btrfs check to
try to fix the FS. Unfortunately, it aborted with:
btrfsck: root-tree.c:81: btrfs_update_root: Assertion `!(ret != 0)' failed.
It means that
While under random IO, a block group's free space cache eventually reaches
a state where it has a mix of extent entries and bitmap entries representing
free space regions.
As later free space regions are returned to the cache, some of them are merged
with existing extent entries if they are
While writing to a file, in inode.c:cow_file_range() (and same applies to
submit_compressed_extents()), after reserving an extent for the file data,
we create a new extent map for the written range and insert it into the
extent map cache. After that, we create an ordered operation, but if it
fails
On Mon, 2014-08-25 at 10:58 +0200, Marc Dietrich wrote:
Am Freitag 22 August 2014, 10:42:18 schrieb Marc Dietrich:
Am Freitag, 22. August 2014, 14:43:45 schrieb Gui Hecheng:
On Thu, 2014-08-21 at 16:19 +0200, Marc Dietrich wrote:
Am Donnerstag, 21. August 2014, 17:52:16 schrieb Gui
On 2014-08-24 15:48, Chris Murphy wrote:
On Aug 24, 2014, at 10:59 AM, Flash ROM flashromg...@yandex.com wrote:
While it sounds dumb, this strange thing being done to put partition table
in separate erase block, so it never read-modify-written when FAT entries
are updated. Should something
Hello!
I am a bit confused about btrfs-progs git repo URLs and branches.
What is the latest stuff that stills supposed to work okay?
My /home BTRFS RAID 1 on two SSDs filesystem has an error with btrfs check that
btrfs-tools 3.14.1 cannot repair.
The repo I found on git.kernel.org
On 08/15/2014 11:36 AM, Liu Bo wrote:
This has been reported and discussed for a long time, and this hang occurs in
both 3.15 and 3.16.
[ great description ]
I ran this through tests last week, and an overnight test over the
weekend. It's in my for-linus branch now, along with everything else
On Mon, Aug 25, 2014 at 10:58:13AM -0400, Chris Mason wrote:
On 08/15/2014 11:36 AM, Liu Bo wrote:
This has been reported and discussed for a long time, and this hang occurs
in
both 3.15 and 3.16.
[ great description ]
I ran this through tests last week, and an overnight test over
On Wed, Aug 20, 2014 at 10:34:53AM +0800, Qu Wenruo wrote:
Although as mentioned in the reply to David,
the main problem is that I found two disk images with crazy values in
superblock and wrong csum,
but generation is still 4, and ignoring the csum error caused kernel BUG.
Can you please
On Aug 25, 2014, at 6:00 AM, Martin Steigerwald mar...@lichtvoll.de wrote:
What is the latest stuff that stills supposed to work okay?
I'm new to git so take this with a grain of salt, but this returns no
differences:
git diff mason/master sterba/v3.16.x
So I'd say we're about to see a
git diff mason/master sterba/integration-20140729
diff --git a/cmds-scrub.c b/cmds-scrub.c
index 731c5c9..0bf06ee 100644
--- a/cmds-scrub.c
+++ b/cmds-scrub.c
@@ -1527,16 +1527,16 @@ out:
static const char * const cmd_scrub_start_usage[] = {
btrfs scrub start [-BdqrRf] [-c ioprio_class
On Aug 25, 2014, at 4:32 PM, David Sterba dste...@suse.cz wrote:
On Mon, Aug 25, 2014 at 04:09:16PM -0600, Chris Murphy wrote:
static const char * const cmd_scrub_start_usage[] = {
btrfs scrub start [-BdqrRf] [-c ioprio_class -n ioprio_classdata]
path|device,
- Start a new
On Mon, Aug 25, 2014 at 10:43:00AM +0100, Filipe Manana wrote:
While writing to a file, in inode.c:cow_file_range() (and same applies to
submit_compressed_extents()), after reserving an extent for the file data,
we create a new extent map for the written range and insert it into the
extent map
13 matches
Mail list logo
