On Tue, Dec 15, 2020 at 8:31 PM Roman Mamedov wrote:
>
> On Mon, 14 Dec 2020 23:27:51 +0100
> Ian Kumlien wrote:
>
> > Aaaand sorry, turns out that my raid device was 1 fifth of its
> > original size and it had to be manually remedied...
> >
> > Now lets see
On Sat, Dec 16, 2017 at 12:07 AM, Hans van Kranenburg
wrote:
> On 12/15/2017 09:53 AM, Qu Wenruo wrote:
>> On 2017年12月15日 16:36, Ian Kumlien wrote:
>>> On Fri, Dec 15, 2017 at 6:34 AM, Roman Mamedov wrote:
>>>> On Fri, 15 Dec 2017 01:39:03 +0100
>>
On Fri, Dec 15, 2017 at 9:53 AM, Qu Wenruo wrote:
> On 2017年12月15日 16:36, Ian Kumlien wrote:
>> On Fri, Dec 15, 2017 at 6:34 AM, Roman Mamedov wrote:
>>> On Fri, 15 Dec 2017 01:39:03 +0100
>>> Ian Kumlien wrote:
>>>
>>>> Hi,
>>>>
On Fri, Dec 15, 2017 at 5:01 AM, Chris Murphy wrote:
> On Thu, Dec 14, 2017 at 5:39 PM, Ian Kumlien wrote:
>> Hi,
>>
>> Running a 4.14.3 kernel, this just happened, but there should have
>> been another 20 gigs or so available.
>>
>> The file
On Fri, Dec 15, 2017 at 6:34 AM, Roman Mamedov wrote:
> On Fri, 15 Dec 2017 01:39:03 +0100
> Ian Kumlien wrote:
>
>> Hi,
>>
>> Running a 4.14.3 kernel, this just happened, but there should have
>> been another 20 gigs or so available.
>>
>> Th
Hi,
Running a 4.14.3 kernel, this just happened, but there should have
been another 20 gigs or so available.
The filesystem seems fine after a reboot though
[1070034.614893] [ cut here ]
[1070034.614899] WARNING: CPU: 4 PID: 18634 at fs/btrfs/inode.c:4647
btrfs_truncate_i
On Wed, Oct 11, 2017 at 2:42 PM, Jeff Mahoney wrote:
> On 10/11/17 2:20 PM, Ian Kumlien wrote:
>>
>>
>> On Wed, Oct 11, 2017 at 2:10 PM Jeff Mahoney > <mailto:je...@suse.com>> wrote:
>>
>> On 10/11/17 12:41 PM, Ian Kumlien wrote:
>>
>&g
Resent since google inbox is still not doing clear-text emails...
On Wed, Oct 11, 2017 at 2:09 PM, Jeff Mahoney wrote:
> On 10/11/17 12:41 PM, Ian Kumlien wrote:
[--8<---]
>> Eventually the filesystem becomes read-only and everything is odd...
>
> Are you still able to
Hi,
I was running a btrfs raid with 6 disks, metadata: dup and data: raid 6
Two of the disks started behaving oddly:
[436823.570296] sd 3:1:0:4: [sdf] Unaligned partial completion
(resid=244, sector_sz=512)
[436823.578604] sd 3:1:0:4: [sdf] Unaligned partial completion
(resid=52, sector_sz=512)
Hi,
I just had my laptop hit the out of space kernel oops which it kinda
hard to recover from
Everything states "out of disk" even with 20 gigs free (both according
to df and btrfs fi df)
So I'm suspecting that i need to run btrfs check on it to recover the
lost space (i have mounted it with cle
We're running a openstack deployment using kolla-ansible on machines
with btrfs filesystems.
kolla-ansible deploys everything as docker images, which in turn uses
btrfs subvolumes and does some heavy-magic^tm
Anyway, a while ago, we restarted one docker instance on four
machines, as you do - pret
On 9 September 2015 at 09:07, Ian Kumlien wrote:
> On 9 September 2015 at 03:35, Anand Jain wrote:
> > There is a patch set to handle this..
> > 'Btrfs: introduce function to handle device offline'
>
> I'll have a look
So from my very quick look at the c
On 9 September 2015 at 03:35, Anand Jain wrote:
> On 09/09/2015 03:34 AM, Hugo Mills wrote:
>>
>> On Tue, Sep 08, 2015 at 09:18:05PM +0200, Ian Kumlien wrote:
>>>
>>> Hi,
>>>
>>> Currently i have a raid1 configuration on two disks where one of t
On 8 September 2015 at 22:28, Hugo Mills wrote:
> On Tue, Sep 08, 2015 at 02:17:55PM -0600, Chris Murphy wrote:
>> On Tue, Sep 8, 2015 at 2:13 PM, Ian Kumlien wrote:
>> > On 8 September 2015 at 22:08, Chris Murphy wrote:
>> >> On Tue, Sep 8, 2015 at 2:00
On 8 September 2015 at 22:17, Chris Murphy wrote:
> On Tue, Sep 8, 2015 at 2:13 PM, Ian Kumlien wrote:
>> On 8 September 2015 at 22:08, Chris Murphy wrote:
>>> On Tue, Sep 8, 2015 at 2:00 PM, Ian Kumlien wrote:
>>
>> [--8<--]
>>
>>>> Some
On 8 September 2015 at 22:08, Chris Murphy wrote:
> On Tue, Sep 8, 2015 at 2:00 PM, Ian Kumlien wrote:
[--8<--]
>> Someone thought they were done too early, only one disk => read only
>> mount. But, readonly mount => no balance.
>>
>> I think something is
On 8 September 2015 at 21:55, Ian Kumlien wrote:
> On 8 September 2015 at 21:43, Ian Kumlien wrote:
>> On 8 September 2015 at 21:34, Hugo Mills wrote:
>>> On Tue, Sep 08, 2015 at 09:18:05PM +0200, Ian Kumlien wrote:
> [--8<--]
>
>>>Physically removing
On 8 September 2015 at 21:43, Ian Kumlien wrote:
> On 8 September 2015 at 21:34, Hugo Mills wrote:
>> On Tue, Sep 08, 2015 at 09:18:05PM +0200, Ian Kumlien wrote:
[--8<--]
>>Physically removing it is the way to go (or disabling it using echo
>> offline >/sys/bl
On 8 September 2015 at 21:34, Hugo Mills wrote:
> On Tue, Sep 08, 2015 at 09:18:05PM +0200, Ian Kumlien wrote:
>> Hi,
>>
>> Currently i have a raid1 configuration on two disks where one of them
>> is failing.
>>
>> But since:
>> btrfs fi df /mn
Hi,
Currently i have a raid1 configuration on two disks where one of them
is failing.
But since:
btrfs fi df /mnt/disk/
Data, RAID1: total=858.00GiB, used=638.16GiB
Data, single: total=1.00GiB, used=256.00KiB
System, RAID1: total=32.00MiB, used=132.00KiB
Metadata, RAID1: total=4.00GiB, used=1.21G
On Thu, Nov 14, 2013 at 01:49:21PM +0100, David Sterba wrote:
> On Thu, Nov 14, 2013 at 11:25:55AM +0200, Ilya Dryomov wrote:
> > On Wed, Nov 13, 2013 at 7:13 PM, David Sterba wrote:
> > >> For this to have any effect, 'h' must be added to getopt_long(), see
> > >> attached patch 1.
> > >>
> > >>
On Sun, Feb 10, 2013 at 01:06:26AM +0300, Sergei Trofimovich wrote:
> On Sat, 9 Feb 2013 19:57:20 +0100
> Ian Kumlien wrote:
>
> > On Sat, Feb 09, 2013 at 09:02:06PM +0300, Sergei Trofimovich wrote:
> > > On Sat, 9 Feb 2013 00:30:21 +0100
> > > Ian Kumlien wr
On Sat, Feb 09, 2013 at 10:48:51PM +0300, Sergei Trofimovich wrote:
> On Sat, 9 Feb 2013 19:51:44 +0100
> Ian Kumlien wrote:
>
> > On Sat, Feb 09, 2013 at 08:57:42PM +0300, Sergei Trofimovich wrote:
> > > On Sat, 9 Feb 2013 00:19:29 +0100
> > > Ian Kumlien wrot
On Sat, Feb 09, 2013 at 09:02:06PM +0300, Sergei Trofimovich wrote:
> On Sat, 9 Feb 2013 00:30:21 +0100
> Ian Kumlien wrote:
>
> > My builds are cluttered with:
> > :0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by
> > default]
> >
> > W
On Sat, Feb 09, 2013 at 08:57:42PM +0300, Sergei Trofimovich wrote:
> On Sat, 9 Feb 2013 00:19:29 +0100
> Ian Kumlien wrote:
>
> > Sometimes, when you least expect it, a static binary is what you need to
> > rescue your data... Or just get a good enough handle on thing
On Sat, Feb 09, 2013 at 12:07:50AM +0100, David Sterba wrote:
> On Fri, Feb 08, 2013 at 07:17:13PM +0100, Ian Kumlien wrote:
> > On Fri, Feb 08, 2013 at 06:39:18PM +0100, Goffredo Baroncelli wrote:
> > > H Iam,
> > >
> > > On 02/08/2013 01:36 AM, Ian Kumlien wr
My builds are cluttered with:
:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by
default]
Which makes it hard to tell if something breaks or not.
Signed-off-by: Ian Kumlien
---
I don't know about you, but bilding with
GCC 4.7.2 on gentoo, this is a issue.
Makefile | 2 +-
ldflags so that
we create a smaller binary, 1.1MB stripped on my 64 bit system
(2.7MB with debug data)
Signed-off-by: Ian Kumlien
---
This is v2 of the patch, David Sterba raised some questions on IRC
and quite correctly pointed out severe problems with the old patch.
The old patch depended on
On Fri, Feb 08, 2013 at 06:39:18PM +0100, Goffredo Baroncelli wrote:
> H Iam,
>
> On 02/08/2013 01:36 AM, Ian Kumlien wrote:
> > This patch includes the functionality of btrfs, it's
> > found as "btrfs check" however it makes the binary
> > behave
On Fri, Feb 08, 2013 at 06:39:12PM +0100, Goffredo Baroncelli wrote:
> On 02/08/2013 01:37 AM, Ian Kumlien wrote:
> > the btrfs command now lists:
> > btrfs rescue select-super -s
> > Select a superblock
> > btrfs rescue dump-super
> >
On Fri, Feb 08, 2013 at 06:40:34PM +0100, Goffredo Baroncelli wrote:
> On 02/08/2013 01:36 AM, Ian Kumlien wrote:
> > Hi,
> >
> > This patch series moves some of the commands around to reflect that
> > they are now subcommands of btrfs.
> >
> > As a stag
The btrfs-restore functionality will be integrated in
btrs as "btrfs restore"
Signed-off-by: Ian Kumlien
---
restore.c => cmds-restore.c | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename restore.c => cmds-restore.c (100%)
diff --git a/restore.c b/cmds-restore.c
simi
This patch includes the functionality of btrfs, it's
found as "btrfs check" however it makes the binary
behave differently depending on what it's run as.
btrfsck -> will act like normal btrfsck
fsck.btrfs -> noop
Signed-off-by: Ian Kumlien
---
Makefile
integrates all the functionality...
cmds-rescue.c is used to glue cmds-rescue-debug-tree.c,
cmds-rescue-restore.c and cmds-rescue-super-ops.c together to
make the source files more managable.
Signed-off-by: Ian Kumlien
---
Makefile | 34 +---
btrfs-dump-super.c
The btrfs-debug-tree functionality will be integrated
in to btrfs as "btrfs rescue debug-tree"
Signed-off-by: Ian Kumlien
---
debug-tree.c => cmds-rescue-debug-tree.c | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename debug-tree.c => cmds-rescue-debug-tree.c (100%)
di
In preparation for merging btrfsck functionality in to btrfs.
Signed-off-by: Ian Kumlien
---
btrfsck.c => cmds-check.c | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename btrfsck.c => cmds-check.c (100%)
diff --git a/btrfsck.c b/cmds-check.c
similarity index 100%
rename from btr
Hi,
This patch series moves some of the commands around to reflect that
they are now subcommands of btrfs.
As a stage in this we also add support for btrfs being called as
btrfsck which yeilds the, now(?), starnard "btrfs check" or
fsck.btrfs which is a noop to avoid complications with distribu
This patch moves
btrfs-select-super.c -> cmds-rescue-super-ops.c
This is done in preparation to merge the select-super
functionality to btrfs.
The naming is because we will also merge
btrfs-dump-super.c from Josef Bacik
Signed-off-by: Ian Kumlien
---
btrfs-select-super.c =>
On Wed, Jan 30, 2013 at 11:59:05PM +0200, Ilya Dryomov wrote:
> On Wed, Jan 30, 2013 at 10:11:44PM +0100, Ian Kumlien wrote:
> > On Wed, Jan 30, 2013 at 12:33:42PM -0800, Filipe Brandenburger wrote:
> > > Hi Ian,
> > >
> > > On Tue, Jan 29, 2013 at 3:03 PM, Ia
On Wed, Jan 30, 2013 at 12:33:42PM -0800, Filipe Brandenburger wrote:
> Hi Ian,
>
> On Tue, Jan 29, 2013 at 3:03 PM, Ian Kumlien wrote:
> > This patch includes fsck as a subcommand of btrfs, but if you rename
> > the binary to btrfsck (or, preferably, use a symlink) it will
This patch includes fsck as a subcommand of btrfs, but if you rename
the binary to btrfsck (or, preferably, use a symlink) it will act like
the old btrfs command.
It will also handle fsck.btrfs which currently is a noop.
---
Makefile| 4 ++--
btrfs.c | 68
NOTE: in order to apply this patch you should:
git mv btrfsck.c cmd-fsck.c
This patch moves btrfsck in to "btrfs fsck".
It also adds support for symlinks to the btrfs binary to
retain compablity, =)
I think something should be done to the help description but i'm not
sure what... Anyway,
On Mon, Jan 28, 2013 at 10:46:51PM +0100, David Sterba wrote:
> Resume: if the distro contains all required libs as static, then your
> patch works.
>
> I wanted to get an idea how the static build would go so my patch
> was a dirty workaroud, that did not work in the end anyway.
To reiterate:
ld
On Mon, Jan 28, 2013 at 10:46:51PM +0100, David Sterba wrote:
> On Mon, Jan 28, 2013 at 07:41:01PM +0100, Ian Kumlien wrote:
> > > I tried to build 'btrfs' only and moved the static libs definition to
> > > the beginning (still needs the uuid static library thou
On Mon, Jan 28, 2013 at 06:05:00PM +0100, David Sterba wrote:
> On Sat, Jan 26, 2013 at 01:09:47AM +0100, Ian Kumlien wrote:
> > Sometimes, when you least expect it, a static binary is what you need to
> > rescue your data... Or just get a good enough handle on things to make
&g
On Sun, Jan 27, 2013 at 12:11:37PM -0500, Gene Czarcinski wrote:
> On 01/25/2013 07:09 PM, Ian Kumlien wrote:
> > Sometimes, when you least expect it, a static binary is what you need to
> > rescue your data... Or just get a good enough handle on things to make
> > it work aga
Sometimes, when you least expect it, a static binary is what you need to
rescue your data... Or just get a good enough handle on things to make
it work again ;)
"make static" is a gift to you, dear user with filesystem problems!
---
Makefile | 4
1 file changed, 4 insertions(+)
diff --git a
And this adds the static compile target... *phew*
--
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://vger.kernel.org/majordomo-info.html
declare btrfs_, verify the memory
and abort() if allocation fails.
Please verify, there is a small glitch about strndup being redefined
during compilation - haven't had time to figure out why this happened.
Another issue is that there seems to be a malloc failure tracking,
which will no longer wo
Sorry about that, selecting a range in git send-email isn't really ovious the
first time you try to select a change in the middle of a log.
--
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:
Sometimes, when you least expect it, a static binary is what you need to
rescue your data... Or just get a good enough handle on things to make
it work again ;)
"make static" is a gift to you, dear user with filesystem problems!
---
Makefile | 4
1 file changed, 4 insertions(+)
diff --git a
On Fri, Jan 25, 2013 at 05:55:16PM -0600, cwillu wrote:
> On Fri, Jan 25, 2013 at 4:55 PM, Ian Kumlien wrote:
> > Hi,
> >
> > Could someone do a sanity check of this, i have removed some of the
> > checking code that is no longer needed but i would prefer to have
>
001
From: Ian Kumlien
Date: Sat, 26 Jan 2013 00:12:28 +0100
Subject: [PATCH] [RFC] Add static compile target
Sometimes, when you least expect it, a static binary is what you need to
rescue your data... Or just get a good enough handle on things to make
it work again ;)
"make static" is a
>From b295b475d60d90b6e66336f28540be2f199ca9b6 Mon Sep 17 00:00:00 2001
From: Ian Kumlien
Date: Fri, 25 Jan 2013 23:44:48 +0100
Subject: [PATCH] [RFC] Abort on memory allocation failure.
declare btrfs_, verify the memory
and abort() if allocation fails.
Please verify, there is a small glitch about strndup being redefine
be done with
this? (It doesn't inspire confidence ;))
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
w i get it, thanks =)
> - Chris.
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
On tis, 2010-02-09 at 16:07 -0500, Chris Ball wrote:
> Hi,
>
>> Will this also fix the directory that i can't delete?
>
> No, I think you need "btrfsctl -D" for that.
btrfsctl -D ext2_saved/
ioctl:: Invalid argument
uname -r
2.6.33-rc7
So i assume it'
On tis, 2010-02-09 at 16:02 -0500, Chris Ball wrote:
> Hi,
>
>> Here's a patch to btrfsck from Josef that should fix this:
>
> Sorry, that was an older patch. This is the working one:
Will test soon!
Will this also fix the directory that i can't delet
otal 4
drwxr-xr-x 1 root root 0 9 feb 13.41 .
drwxr-xr-x 1 root root 170 2 dec 21.54 ..
Any clues, ideas, suggestions?
(Remember the CC)
PS. Beyond that i really like my experiences with btrfs so far (this was
my first root filesystem migration though)
DS.
--
Ian Kumlien -- http://pom
59 matches
Mail list logo
