Hi,
Kernel 3.12-rc built from HEAD has the same issue as 3.10 and 3.11
Ok, I was able to "fix" my problem by booting from an old kernel
(3.8.7) and it allowed me to mount the fs. Then I removed
/var/log/journal directory. After that I was able to boot with 3.11.
So I believe 3.9/3.10 has a regres
Hi Linus,
We've got more bug fixes in my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
One of these fixes another corner of the compression oops from last
time. Miao nailed down some problems with concurrent snapshot deletion
and drive balancing
I'm going to be removing hole extents in the near future so I wanted to make a
sanity test for btrfs_get_extent to make sure I don't break anything in the
meantime. This patch just puts btrfs_get_extent through its paces by giving it
a completely unreasonable mapping to look at and make sure it is
On 10/11/2013 20:35, Geyslan G. Bem wrote:
In add_inode_ref() function:
Initializes local pointers.
Reduces the logical condition with the __add_inode_ref() return
value by using only one 'goto out'.
Centralizes the exiting, ensuring the freeing of all used memory.
Signed-off-by: Geyslan G. B
In add_inode_ref() function:
Initializes local pointers.
Reduces the logical condition with the __add_inode_ref() return
value by using only one 'goto out'.
Centralizes the exiting, ensuring the freeing of all used memory.
Signed-off-by: Geyslan G. Bem
---
fs/btrfs/tree-log.c | 33 +++
From: Wang Shilong
We only allocate scrub workers if we pass all the necessary
checks, for example, there are no operation in progress.
Besides, move mutex lock protection outside of scrub_workers_get()
/scrub_workers_put().
Signed-off-by: Wang Shilong
---
fs/btrfs/scrub.c | 23 ++
> a filesystem is mounted. They set the device stats to zero by using
> kzalloc() which is correct for new devices.
Oh, right, got it :)
- z
--
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
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 646d10d..9837439 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -2041,6 +2041,7 @@ int btrfs_init_new_device(struct btrfs_root *root, char
> *device_path)
> device->in_fs_metadata = 1;
> device->is_tgtdev
On Fri, Oct 11, 2013 at 12:42 PM, David Sterba wrote:
> On Sun, Oct 06, 2013 at 10:22:33PM +0100, Filipe David Borba Manana wrote:
>> 2) On 32 bits machines. Th VFS hash values are unsigned longs, which
>>are 32 bits wide on 32 bits machines, and the inode (objectid)
>>numbers are 64 bits
On 10/11/13 10:14 AM, Emil Karlson wrote:
>> If the filesystem is clever enough to know that the range in question has
>> not been written to since the last discard, then it takes no action, and
>> reports zero bytes.
>
> File system images can be rewritten on a new media so there is a
> drawback
If the user remounts the filesystem read-only while the uuid-tree
scan and rebuild task is still running (this happens once after the
filesystem was mounted with an old kernel, or when forced with the
mount options), the remount should wait on the tasks completion
before setting the filesystem read
> If the filesystem is clever enough to know that the range in question has
> not been written to since the last discard, then it takes no action, and
> reports zero bytes.
File system images can be rewritten on a new media so there is a
drawback to that.
Best Regards
-Emil
--
To unsubscribe from
On 10/10/13 6:39 AM, Duncan wrote:
> Mike Audia posted on Thu, 10 Oct 2013 06:20:42 -0400 as excerpted:
>
>> I think I found a bug affecting btrfs filesystems and users invoking
>> fstrim to discard unused blocks: if I execute a `fstrim -v /` twice, the
>> amount trimmed does not change on the 2nd
On Fri, Oct 11, 2013 at 04:07:37PM +0200, Stefan Behrens wrote:
> On Fri, 11 Oct 2013 09:47:33 -0400, Josef Bacik wrote:
> > Hey look something else that should go into xfstests,
>
> I don't think so. It's a bug that is there from the very beginning, not
> a regression. We can't catch all possible
On Fri, 11 Oct 2013 09:47:33 -0400, Josef Bacik wrote:
> Hey look something else that should go into xfstests,
I don't think so. It's a bug that is there from the very beginning, not
a regression. We can't catch all possible errors (non-regressions) with
xfstests. We would spend all time for writi
On Fri, Oct 11, 2013 at 02:18:23PM +0200, Stefan Behrens wrote:
> Currently the attempt to reset the device statistics with
> 'btrfs device stat -z ...' on read-only filesystems does not return an
> error. The statistics that are hold in main memory are reset but the
> statistics that are stored in
On Fri, Oct 11, 2013 at 03:20:42PM +0200, Stefan Behrens wrote:
> Device stats are only initialized (read from tree items) on mount.
> Trying to read device stats after adding or replacing new devices will
> return errors.
>
> btrfs_init_new_device() and btrfs_init_dev_replace_tgtdev() are the two
Device stats are only initialized (read from tree items) on mount.
Trying to read device stats after adding or replacing new devices will
return errors.
btrfs_init_new_device() and btrfs_init_dev_replace_tgtdev() are the two
functions that allocate and initialize new btrfs_device structures after
2013/10/11 Stefan Behrens :
> On Thu, 10 Oct 2013 19:11:22 -0300, Geyslan G. Bem wrote:
>> In add_inode_ref() function:
>>
>> Initializes local pointers.
>>
>> Reduces the logical condition with the __add_inode_ref() return
>> value by using only one 'goto out'.
>>
>> Centralizes the exiting, ensur
On Thu, 10 Oct 2013 19:11:22 -0300, Geyslan G. Bem wrote:
> In add_inode_ref() function:
>
> Initializes local pointers.
>
> Reduces the logical condition with the __add_inode_ref() return
> value by using only one 'goto out'.
>
> Centralizes the exiting, ensuring the freeing of all used memory.
Currently the attempt to reset the device statistics with
'btrfs device stat -z ...' on read-only filesystems does not return an
error. The statistics that are hold in main memory are reset but the
statistics that are stored in the filesystem are not reset.
Fix it by returning EROFS in this case.
with this patch, BTRFS_SCAN_LBLKID (which leverages lblkid
to look for btrfs disks) would be the default scan method
to look for the btrfs disks. And thus the output as seen
in the latest btrfs fi show and btrfs fi show -m for the
mounted disks will have the consistent disks path.
(it was inconsist
Signed-off-by: Anand Jain
---
cmds-device.c |2 +-
utils.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmds-device.c b/cmds-device.c
index 1315918..6f32356 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -203,7 +203,7 @@ static int cmd_scan_dev(int argc,
On Sun, Oct 06, 2013 at 10:22:33PM +0100, Filipe David Borba Manana wrote:
> 2) On 32 bits machines. Th VFS hash values are unsigned longs, which
>are 32 bits wide on 32 bits machines, and the inode (objectid)
>numbers are 64 bits unsigned integers. We simply cast the inode
>numbers to
On Fri, Oct 11, 2013 at 03:35:46PM +0600, Roman Mamedov wrote:
> On Fri, 11 Oct 2013 11:23:04 +0200
> Stefan Behrens wrote:
>
> > On Fri, 11 Oct 2013 09:13:24 +0800, Wang Shilong wrote:
> > > On 10/11/2013 01:40 AM, Ilya Dryomov wrote:
> > >
> > > I have a question in my mind.
> > >
> > > Can w
On Fri, 11 Oct 2013 11:23:04 +0200
Stefan Behrens wrote:
> On Fri, 11 Oct 2013 09:13:24 +0800, Wang Shilong wrote:
> > On 10/11/2013 01:40 AM, Ilya Dryomov wrote:
> >
> > I have a question in my mind.
> >
> > Can we reach a state that there is operation in progress when filesystem
> > has been
On Fri, Oct 11, 2013 at 12:28 PM, Remco Hosman - Yerf-IT
wrote:
> i would expect a RO mount never to write anything to a filesystem. not even
> replay a journal (or a seperate option for that).
> Its possible that the device is not writable at all, if its a snapshot or a
> RO iscsi device of some
On Fri, Oct 11, 2013 at 4:13 AM, Wang Shilong
wrote:
> On 10/11/2013 01:40 AM, Ilya Dryomov wrote:
>
> I have a question in my mind.
>
> Can we reach a state that there is operation in progress when filesystem
> has been readonly?If we do cancel operations on a ro filesystem, we should
> get "No o
Op 11-10-2013 11:23, Stefan Behrens schreef:
On Fri, 11 Oct 2013 09:13:24 +0800, Wang Shilong wrote:
On 10/11/2013 01:40 AM, Ilya Dryomov wrote:
I have a question in my mind.
Can we reach a state that there is operation in progress when filesystem
has been readonly?If we do cancel operations o
On Fri, 11 Oct 2013 09:13:24 +0800, Wang Shilong wrote:
> On 10/11/2013 01:40 AM, Ilya Dryomov wrote:
>
> I have a question in my mind.
>
> Can we reach a state that there is operation in progress when filesystem
> has been readonly?If we do cancel operations on a ro filesystem, we should
> get "
When we fail to add a reference after a non-inline insertion by some reasons,
eg. ENOSPC, we'll abort the transaction, but we don't return this error to
the caller who has to walk around again to find something wrong, that's
unnecessary.
Also fixup other error paths to keep it simple.
Signed-off-
Hello Daniel,
On 10/11/2013 03:52 PM, Daniel wrote:
Hello Josef,
Josef Bacik fusionio.com> writes:
On Thu, Sep 05, 2013 at 10:45:23AM -0500, Eric Sandeen wrote:
[...]
This was a regression around July 3; there was no regression test at
the time.
[615f2867854c186a37cb2e2e5a2e13e9ed4ab0df]
Hello Josef,
Josef Bacik fusionio.com> writes:
>
> On Thu, Sep 05, 2013 at 10:45:23AM -0500, Eric Sandeen wrote:
[...]
> > This was a regression around July 3; there was no regression test at
> > the time.
> >
> > [615f2867854c186a37cb2e2e5a2e13e9ed4ab0df] Btrfs-progs: cleanup similar
code
33 matches
Mail list logo
