On 2016 Sep 20, Peter Becker wrote:
> Data, RAID1: total=417.12GiB, used=131.33GiB
>
> You have 417(total)-131(used) blocks wo are only partial filled.
> You should balance your file-system.
>
> At first you need some free space. You could remove some files / old
> snapshots etc. or you add a emp
On Tue, 16 Sep 2014 01:39:49 +0800
Anand Jain wrote:
>
>
> On 16/09/2014 01:14, Johannes Hirte wrote:
> > On Mon, 15 Sep 2014 20:32:58 +0800
> > Anand Jain wrote:
> >
> >>
> >>
> >> Hi Johannes,
> >>
> >>Can I have
On Mon, 15 Sep 2014 20:32:58 +0800
Anand Jain wrote:
>
>
> Hi Johannes,
>
> Can I have you this tested.. ? Thanks.
>
>
> ---
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index e9676a4..1224b61 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -533,7 +533,7 @
On Sun, 14 Sep 2014 00:45:49 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> Johannes Hirte posted on Sat, 13 Sep 2014 23:23:20 +0200 as excerpted:
>
> > On Sat, 13 Sep 2014 19:55:25 +0200 Johannes Hirte
> > wrote:
> >
> >> On Sat, 13 Sep 201
On Sat, 13 Sep 2014 19:55:25 +0200
Johannes Hirte wrote:
> On Sat, 13 Sep 2014 13:36:37 +0800
> Anand Jain wrote:
>
> > Xavier, Johannes,
> >
> > The quickest workaround for you will be to try to match
> > the device path as in the btrfs fi show -m ou
On Sat, 13 Sep 2014 13:36:37 +0800
Anand Jain wrote:
> Xavier, Johannes,
>
> The quickest workaround for you will be to try to match
> the device path as in the btrfs fi show -m output to
> your probably fstab/mnttab entry.
Doesn't work here. I don't even get a path with the affected
commit b96de000bc8bc9688b3a2abea4332bd57648a49f breaks subvolume mount
on one of my systems. I've bisected a mount problem to this commit.
Situation is:
- one hdd with btrfs
- default subvolume (rootfs) is different from subovlid=0
- at boot, several subvols are mounted at /home/$DIR
after commit
On Fri, 04 Apr 2014 08:33:10 -0400
Austin S Hemmelgarn wrote:
> On 2014-04-04 04:02, Swâmi Petaramesh wrote:
> > - Is it still recommended to mkfs with a nodesize or leafsize
> > different (bigger) than the default ? I wouldn't like to lose too
> > much disk space anyway (1/2 nodesize per file on
On Fri, 14 Feb 2014 14:29:35 -0500
Josef Bacik wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 02/14/2014 02:25 PM, Johannes Hirte wrote:
> > On Thu, 6 Feb 2014 16:19:46 -0500 Josef Bacik
> > wrote:
> >
> >> Ok so I thought I
On Thu, 6 Feb 2014 16:19:46 -0500
Josef Bacik wrote:
> Ok so I thought I reproduced the problem but I just reproduced a
> different problem. Please undo any changes you've made and apply
> this patch and reproduce and then provide me with any debug output
> that gets spit out. I'm sending this
On Wed, 5 Feb 2014 16:46:57 -0500
Josef Bacik wrote:
>
> On 02/05/2014 04:42 PM, Johannes Hirte wrote:
> > On Wed, 5 Feb 2014 14:36:39 -0500
> > Josef Bacik wrote:
> >
> >> On 02/05/2014 02:30 PM, Johannes Hirte wrote:
> >>> On Wed, 5 Feb
On Wed, 5 Feb 2014 14:36:39 -0500
Josef Bacik wrote:
>
> On 02/05/2014 02:30 PM, Johannes Hirte wrote:
> > On Wed, 5 Feb 2014 14:00:57 -0500
> > Josef Bacik wrote:
> >
> >> On 02/05/2014 12:34 PM, Johannes Hirte wrote:
> >>> On Wed, 5 Feb
On Wed, 5 Feb 2014 10:49:15 -0500
Josef Bacik wrote:
> Ok none of those make sense which makes me think it may be the ktime
> bits, instead of un-applying the whole patch could you just comment
> out the parts
>
> ktime_t start = ktime_get();
>
> and
>
> if (actual_count > 0
On Tue, 4 Feb 2014 09:12:54 -0500
Josef Bacik wrote:
> Hrm I was hoping that was going to be more helpful. Can you get perf
> record -ag and then perf report while it's at full cpu and get the
> first 3 or 4 things with their traces?
Here it comes:
#
# captured on: Wed Feb 5 00:11:4
On Mon, 3 Feb 2014 16:08:08 -0500
Josef Bacik wrote:
>
> On 02/03/2014 01:28 PM, Johannes Hirte wrote:
> > On Thu, 23 Jan 2014 13:07:52 -0500
> > Josef Bacik wrote:
> >
> >> On one of our gluster clusters we noticed some pretty big lag
> >>
On Thu, 23 Jan 2014 13:07:52 -0500
Josef Bacik wrote:
> On one of our gluster clusters we noticed some pretty big lag
> spikes. This turned out to be because our transaction commit was
> taking like 3 minutes to complete. This is because we have like 30
> gigs of metadata, so our global reserve
On Fri, 27 Sep 2013 09:37:00 -0400
Josef Bacik wrote:
> A user reported a problem where they were getting csum errors when
> running a balance and running systemd's journal. This is because
> systemd is awesome and fallocate()'s its log space and writes into
> it. Unfortunately we assume that w
On Tue, 24 Sep 2013 22:34:20 -0600
Chris Murphy wrote:
> OK so I think I'm narrowing this down to just the systemd journal,
> and it's not checksums that are corrupted, it's the journal itself.
I doubt it's systemd-dependent, cause I've seen similar behaviour on a
Gentoo system without systemd.
On Tue, 18 Jun 2013 17:19:04 + (UTC)
Jon Nelson wrote:
> Josef Bacik fusionio.com> writes:
>
> >
> > On Tue, Jun 11, 2013 at 11:43:30AM -0400, Sage Weil wrote:
> > > I'm also seeing this hang regularly with both 3.9 and 3.10-rc5.
> > > Is this is a known problem? In this case there is no
On Tue, 12 Mar 2013 09:39:35 +0800
Liu Bo wrote:
> Hi Johannes,
>
> Could you please tell us what mount options you're with?
>
> thanks,
> liubo
The Filesystem has six subvolumes, so mount options are:
noatime,inode_cache,autodefrag,subvolid=...
for each subvol.
I was able to reproduce it a
Since the updates for linux-3.9 I've had three or four times a system
freeze and only a reset (Magic SysRq) helped. After the reboot I found
a bunch of this in syslog:
Mar 11 21:56:09 localhost kernel: [ cut here ]
Mar 11 21:56:09 localhost kernel: WARNING: at fs/btrfs/exte
On Thu, 21 Feb 2013 18:47:28 +0100
Swâmi Petaramesh wrote:
> Le 21/02/2013 18:25, Hugo Mills a écrit :
> > Correct. But btrfs isn't at that stage yet. It's getting visibly
> > closer, but it's not quite there. Hence the very strong
> > recommendation to keep up with the latest code. Hugo.
>
> T
Am Mon, 7 May 2012 12:39:28 +0100
schrieb Hugo Mills :
> On Mon, May 07, 2012 at 01:15:26PM +0200, Alessio Focardi wrote:
...
> > That's a very clever suggestion, I'm preparing a test server right
> > now: going to use the -m single option. Any other suggestion
> > regarding format options?
> >
>
Am Mon, 12 Mar 2012 15:21:49 +0100
schrieb Jacek Luczak :
> > 2) A *regression* in 3.3.0-rc6-00197-g9f8050c
> > - completely unusable as reports ENOSPC
> > - to reproduce, mount volume and issue:
> > # CNT=1 ; while [ $CNT -lt 1 ] ; do rm -f /btrfs/dd ; ! touch
> > /btrfs/dd && echo "$CNT" &&
Am Fri, 09 Mar 2012 09:28:56 +0800
schrieb Liu Bo :
> On 03/09/2012 03:22 AM, Johannes Hirte wrote:
> > Am Tue, 6 Mar 2012 14:50:32 +0100
> > schrieb Johannes Hirte :
> >
> >> I've backed up the filesystem, deleted the subvolumes, recreated
> >> t
Am Sat, 25 Feb 2012 20:05:13 -0800
schrieb Fahrzin Hemmati :
> No, at least not yet, nor am I aware of any plans for subvolume
> quotas, though I could be wrong.
Arne Jansen is working on it, IIRC.
regards,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
Am Tue, 6 Mar 2012 14:50:32 +0100
schrieb Johannes Hirte :
> I've backed up the filesystem, deleted the subvolumes, recreated them
> and copied the data back. Now everything seems to work again. I've
> also a full image of the damaged filesystem for further
> investigation.
Am Tue, 28 Feb 2012 10:06:14 +0800
schrieb Liu Bo :
> On 02/27/2012 09:29 PM, Johannes Hirte wrote:
> > Am Tue, 17 Jan 2012 17:51:59 +0800
> > schrieb Liu Bo :
> >
> >> I've kept hitting enospc warnings of global_rsv while running
> >> defragment
Am Tue, 17 Jan 2012 17:51:59 +0800
schrieb Liu Bo :
> I've kept hitting enospc warnings of global_rsv while running
> defragment on files:
> btrfs: block rsv returned -28
> WARNING: at fs/btrfs/extent-tree.c:5984
> btrfs_alloc_free_block+0x333/0x340 [btrfs]() ...
>
> I used a fio jobs to create a
On Friday 10 June 2011 01:53:41 David Sterba wrote:
> On Fri, Jun 10, 2011 at 12:48:36AM +0200, Johannes Hirte wrote:
> > I've observed several times that after a btrfs filesystem defrag a file
> > was way more fragmented than before. For example, a file that was
> >
After some problems with btrfs (Oopses), I've checked now the btrfs filesystems
on my systems as a precaution. On the first system I got
root 256 inode 404596 errors 400
root 256 inode 404603 errors 400
root 256 inode 409540 errors 400
root 256 inode 409562 errors 400
root 258 inode errors 4
I've observed several times that after a btrfs filesystem defrag a file was way
more fragmented than before. For example, a file that was recently written, had
10 extents (output from filefrag). After a defrag filefrag showed more than
1900
extents. For curiosity, a simple copy of this "defragm
On Friday 03 June 2011 18:24:41 Arne Jansen wrote:
> Hi,
>
> If no one is already working on it, I'd like to take the Quota lock and
> see how far I come.
> Let me sketch out in short what I'm planning to do:
>
> - Quota will be subvolume based. Only the FS-trees and data extents
> will be
On Thursday 05 May 2011 22:32:42 Chris Mason wrote:
> Excerpts from Konstantinos Skarlatos's message of 2011-05-05 16:27:54 -0400:
> > I think i made some progress. When i tried to remove the directory that
> > i suspect contains the problematic file, i got this on the console
> >
> > rm -rf serve
On Monday 25 April 2011 10:57:47 Li Zefan wrote:
> Currently btrfs stores the highest objectid of the fs tree, and it always
> returns (highest+1) inode number when we create a file, so inode numbers
> won't be reclaimed when we delete files, so we'll run out of inode numbers
> as we keep create/de
On Wednesday 06 April 2011 19:15:41 Josef Bacik wrote:
> On Wed, Apr 06, 2011 at 01:10:38PM +0200, Johannes Hirte wrote:
> > On Tuesday 05 April 2011 23:57:53 Josef Bacik wrote:
> > > > Now it hit
> > >
> > > Man I cannot catch a break. I hope this is the
On Wednesday 06 April 2011 22:47:28 Jordan Patterson wrote:
> Hi Josef:
>
> I tried your latest patch, since I had the same issue from the first
> email. With the patch applied, I am now hitting the
> BUG_ON(block_group->total_bitmaps >= max_bitmaps); in add_new_bitmap
> in
> fs/btrfs/free-space-
On Tuesday 05 April 2011 23:57:53 Josef Bacik wrote:
> > Now it hit
>
> Man I cannot catch a break. I hope this is the last one. Thanks,
>
> Josef
>
> ---
> fs/btrfs/free-space-cache.c | 32
> 1 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git
On Tuesday 05 April 2011 23:12:27 Josef Bacik wrote:
> On Tue, Apr 05, 2011 at 11:08:52PM +0200, Johannes Hirte wrote:
> > On Tuesday 05 April 2011 21:31:43 Josef Bacik wrote:
> > > On Tue, Apr 05, 2011 at 09:21:55PM +0200, Johannes Hirte wrote:
> > > > On Tuesda
On Tuesday 05 April 2011 20:53:24 Josef Bacik wrote:
> On Tue, Apr 05, 2011 at 08:52:21PM +0200, Johannes Hirte wrote:
> > On Tuesday 05 April 2011 19:42:03 Josef Bacik wrote:
> > > On Tue, Apr 05, 2011 at 07:38:13PM +0200, Johannes Hirte wrote:
> > > > With the la
On Tuesday 05 April 2011 19:42:03 Josef Bacik wrote:
> On Tue, Apr 05, 2011 at 07:38:13PM +0200, Johannes Hirte wrote:
> > With the latest btrfs changes, I got this Oops when doing rm on a large
> > directory:
> >
> > BUG: unable to handle kernel NULL pointer der
With the latest btrfs changes, I got this Oops when doing rm on a large
directory:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] kunmap+0x46/0x46
*pdpt = 34a85001 *pde =
Oops: [#1] PREEMPT SMP
last sysfs file: /sys/devices/virtual/vtconso
On Monday 07 March 2011 20:56:50 Maria Wikström wrote:
> mån 2011-03-07 klockan 00:07 -0600 skrev Mitch Harder:
> > On Sun, Mar 6, 2011 at 6:58 PM, Chris Mason
wrote:
> > > Excerpts from Chris Mason's message of 2011-03-06 13:00:27 -0500:
> > >> Excerpts from Mitch Harder's message of 2011-03-05
On Monday 28 February 2011 02:46:05 Chris Mason wrote:
> Excerpts from Mitch Harder's message of 2011-02-25 13:43:37 -0500:
> > Some clarification on my previous message...
> >
> > After looking at my ftrace log more closely, I can see where Btrfs is
> > trying to release the allocated pages. How
On Wednesday 23 February 2011 22:56:27 Chris Mason wrote:
> Excerpts from Zhong, Xin's message of 2011-02-23 02:27:05 -0500:
> > In the dmesg of rc4, I can see svn hang in shrink_dellalloc and there's
> > two flush-btrfs threads hang there too.
> >
> > Josef, it seems you are the expert in this ar
On Friday 28 January 2011 04:53:24 Zhong, Xin wrote:
> Could you describe the steps to recreate it?
> It will be a great help for me to look further. Thanks!
It's a little strange. I have to systems with btrfs, both Gentoo-based. One is
affected by this bug the other is not. On the affected syste
On Friday 28 January 2011 02:26:43 Zhong, Xin wrote:
> Please try the fix in below link:
> http://www.spinics.net/lists/linux-btrfs/msg08051.html
>
> Thanks!
This doesn't fix it for me. At least there is a difference. Whereas the svn
process started consuming 100% CPU without any further interac
On Thursday 09 December 2010 10:30:14 Zhong, Xin wrote:
> This problem is found in meego testing:
> http://bugs.meego.com/show_bug.cgi?id=6672
> A file in btrfs is mmaped and the mmaped buffer is passed to pwrite to
> write to the same page of the same file. In btrfs_file_aio_write(), the
> pages i
On Monday 24 January 2011 09:33:00 Helmut Hullen wrote:
> Hallo, Chris,
>
> Du meintest am 24.01.11:
> >> Thank you - that's more simple for me than first cloning via
> >> "git clone" and then running "git log".
> >
> > Ah, but the repo you were asked to clone was for the user tools,
> > not for
On Thursday 02 December 2010 20:21:30 Chris Mason wrote:
> Excerpts from Johannes Hirte's message of 2010-12-02 12:02:16 -0500:
> > On Thursday 02 December 2010 17:52:50 Johannes Hirte wrote:
> > > On Thursday 02 December 2010 17:19:56 Chris Mason wrote:
> > >
On Friday 03 December 2010 01:44:49 C Anthony Risinger wrote:
> Did you fix that typo I posted?
>
> C Anthony [mobile]
>
Yes, without fix it wouldn't compile.
regards,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger
On Thursday 02 December 2010 21:34:10 Josef Bacik wrote:
> On Wed, Dec 01, 2010 at 10:40:29PM +0100, Johannes Hirte wrote:
> > On Wednesday 01 December 2010 22:22:45 Johannes Hirte wrote:
> > > On Wednesday 01 December 2010 21:03:13 Josef Bacik wrote:
> > > > On W
On Thursday 02 December 2010 17:52:50 Johannes Hirte wrote:
> On Thursday 02 December 2010 17:19:56 Chris Mason wrote:
> > Excerpts from Johannes Hirte's message of 2010-12-01 08:11:01 -0500:
> > > On one of my machines with btrfs I got this bug:
> > >
> >
On Thursday 02 December 2010 17:19:56 Chris Mason wrote:
> Excerpts from Johannes Hirte's message of 2010-12-01 08:11:01 -0500:
> > On one of my machines with btrfs I got this bug:
> >
> > entry offset 29085974528, bytes 4096, bitmap no
> > entry offset 29162995712, bytes 20480, bitmap yes
> > ent
On Wednesday 01 December 2010 22:22:45 Johannes Hirte wrote:
> On Wednesday 01 December 2010 21:03:13 Josef Bacik wrote:
> > On Wed, Dec 01, 2010 at 08:56:14PM +0100, Johannes Hirte wrote:
> > > On Wednesday 01 December 2010 18:40:18 Josef Bacik wrote:
> > > > On W
On Wednesday 01 December 2010 21:03:13 Josef Bacik wrote:
> On Wed, Dec 01, 2010 at 08:56:14PM +0100, Johannes Hirte wrote:
> > On Wednesday 01 December 2010 18:40:18 Josef Bacik wrote:
> > > On Wed, Dec 01, 2010 at 05:46:14PM +0100, Johannes Hirte wrote:
> > > > Aft
On Wednesday 01 December 2010 18:40:18 Josef Bacik wrote:
> On Wed, Dec 01, 2010 at 05:46:14PM +0100, Johannes Hirte wrote:
> > After enabling disk space caching I've observed several log entries like
> > this:
> >
> > btrfs: free space inode generation (0
After enabling disk space caching I've observed several log entries like this:
btrfs: free space inode generation (0) did not match free space cache
generation (169594) for block group 15464398848
I'm not sure, but it seems this happens on every reboot. Is this something to
worry about?
regards
On one of my machines with btrfs I got this bug:
entry offset 29085974528, bytes 4096, bitmap no
entry offset 29162995712, bytes 20480, bitmap yes
entry offset 29171744768, bytes 4096, bitmap no
block group has cluster?: no
0 blocks of free space at or bigger than bytes is
block group 29834084352
On Friday 10 September 2010 21:46:49 Marcel Lohmann wrote:
> Trying to use "-l 2048" during mkfs was rejected as being invalid. But
> who cares...?
>
> Marcel
That's because btrfs supports only leafsize equal to pagesize for now.
regards,
Johannes
--
To unsubscribe from this list: send the lin
On Thursday 26 August 2010 15:39:25 Andreas Philipp wrote:
> On 26.08.2010 15:27, Johannes Hirte wrote:
> > Looks like another manifestation of the csum bug. Are you able to read all
> > files from the affected volume? Did you tried a balance with an 2.6.34
> > kernel
&g
On Saturday 14 August 2010 00:11:55 Andreas Philipp wrote:
> On 12.08.2010 10:04, Yan, Zheng wrote:
> > On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp
> > wrote:
> >
> >> Hi,
> >>
> >> I am using a btrfs filesystem created with raid0 for data and metadata
> >> for (temporary) storage of tv re
On Monday 16 August 2010 16:17:54 Morten P.D. Stevens wrote:
> Hi Chris,
>
> the other big question is:
>
> Is btrfs with 2.6.36 really rockstable and ready to use in productive
> environments?
>
> Thanks
>
> Morten
I don't think so. There is at least one checksum bug and ENOSPC problems are
Am Donnerstag 22 Juli 2010, 20:07:23 schrieb Johannes Hirte:
> Am Montag 19 Juli 2010, 10:01:46 schrieb Miao Xie:
> > On Thu, 15 Jul 2010 20:14:51 +0200, Johannes Hirte wrote:
> > > Am Donnerstag 15 Juli 2010, 02:11:04 schrieb Dave Chinner:
> > >> On Wed, Jul 14, 2010
Am Montag 19 Juli 2010, 10:01:46 schrieb Miao Xie:
> On Thu, 15 Jul 2010 20:14:51 +0200, Johannes Hirte wrote:
> > Am Donnerstag 15 Juli 2010, 02:11:04 schrieb Dave Chinner:
> >> On Wed, Jul 14, 2010 at 05:25:23PM +0200, Johannes Hirte wrote:
> >>> Am Donnerstag
Am Freitag 16 Juli 2010, 13:55:26 schrieb Edward Ned Harvey:
> Is this a good place to get a clue about the status of BTRFS? Like ... Is
> it usable yet, and stuff like that?
>
> Thank you...
I wouldn't suggest to use it in productive environments. Especially as the
error handling is very rudi
Am Donnerstag 15 Juli 2010, 20:14:51 schrieb Johannes Hirte:
> Am Donnerstag 15 Juli 2010, 02:11:04 schrieb Dave Chinner:
> > On Wed, Jul 14, 2010 at 05:25:23PM +0200, Johannes Hirte wrote:
> > > Am Donnerstag 08 Juli 2010, 16:31:09 schrieb Chris Mason:
> > > I'm n
Am Donnerstag 15 Juli 2010, 21:35:51 schrieb Chris Mason:
> On Thu, Jul 15, 2010 at 09:32:12PM +0200, Johannes Hirte wrote:
> > Am Donnerstag 15 Juli 2010, 21:03:09 schrieb Chris Mason:
> > > On Thu, Jul 15, 2010 at 08:30:17PM +0200, Johannes Hirte wrote:
> > > > Am D
Am Donnerstag 15 Juli 2010, 21:03:09 schrieb Chris Mason:
> On Thu, Jul 15, 2010 at 08:30:17PM +0200, Johannes Hirte wrote:
> > Am Dienstag 13 Juli 2010, 14:23:58 schrieb Johannes Hirte:
> > > ino 1959333 off 898342912 csum 4271223884 private 4271223883
> >
> > I th
Am Dienstag 13 Juli 2010, 14:23:58 schrieb Johannes Hirte:
> On the Opteron system I got now csum errors. I've synced some data from the
> netbook to the Opteron yesteray. After hitting ENOSPC with 4GB free, I've
> run 'btrfs-vol -b' on this fs in hope to get some mor
Am Donnerstag 15 Juli 2010, 02:11:04 schrieb Dave Chinner:
> On Wed, Jul 14, 2010 at 05:25:23PM +0200, Johannes Hirte wrote:
> > Am Donnerstag 08 Juli 2010, 16:31:09 schrieb Chris Mason:
> > I'm not sure if btrfs is to blame for this error. After the errors I
> > switched
8, 2010 at 04:27:23PM +0200, Johannes Hirte wrote:
> > When doing a 'rm -r /var/tmp/portage/sys-devel' I get the following Oops:
> >
> > [ cut here ]
> > kernel BUG at fs/btrfs/extent-tree.c:1353!
> > invalid opcode: [#1] PREEMPT S
Am Sonntag 11 Juli 2010, 14:28:09 schrieb Johannes Hirte:
...
> I've three systems running with btrfs, a dual Opteron (252), a Pentium 4
> system and a netbook with N270 Atom. The netbook is the only one that shows
> the errors. It's also the only system where I'm usi
It's getting worse. The /home partition is now affected too. I get the Oops on
simple unmounting the fs. btrfsck gives me this output on this fs:
btrfsck /dev/mapper/sdb3
leaf 123780497408 items 49 free space 271 generation 62207 owner 2
fs uuid 7f013285-88d8-452f-a139-7d44bffd14b6
chunk uuid 36
Am Donnerstag 08 Juli 2010, 16:31:09 schrieb Chris Mason:
> Neither Yan nor I have been able to reproduce this locally, but a few
> people have now hit it. Johannes, are you available to try out a
> debugging kernel to try and track this down?
Sure, just tell me what to do. Is it enough to recomp
When doing a 'rm -r /var/tmp/portage/sys-devel' I get the following Oops:
[ cut here ]
kernel BUG at fs/btrfs/extent-tree.c:1353!
invalid opcode: [#1] PREEMPT SMP
last sysfs file:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/charge_full
Modules l
Am Donnerstag 17 Juni 2010, 02:47:07 schrieb Yan, Zheng:
> On Thu, Jun 17, 2010 at 7:56 AM, Johannes Hirte
>
> wrote:
> > Am Donnerstag 17 Juni 2010, 01:12:54 schrieb Yan, Zheng:
> >> On Thu, Jun 17, 2010 at 1:48 AM, Johannes Hirte
> >>
> >> wrote
Am Donnerstag 17 Juni 2010, 01:12:54 schrieb Yan, Zheng:
> On Thu, Jun 17, 2010 at 1:48 AM, Johannes Hirte
>
> wrote:
> > With kernel-2.6.34 I run into the ENOSPC problems that where reported on
> > this list recently. The filesystem was somewhat over 90% full and most
Am Dienstag 15 Juni 2010, 02:08:20 schrieb Chris Mason:
> On Mon, Jun 14, 2010 at 11:45:40PM +0200, Johannes Hirte wrote:
> > Am Montag 14 Juni 2010, 23:16:01 schrieb Christoph Hellwig:
> > > On Mon, Jun 14, 2010 at 11:11:20PM +0200, Dan Carpenter wrote:
> > > > &
With kernel-2.6.34 I run into the ENOSPC problems that where reported on this
list recently. The filesystem was somewhat over 90% full and most operations on
it caused a Oops. I was able to delete files by trial and error and freed up
half of the filesystem space. Operation on the other files st
Am Montag 14 Juni 2010, 23:16:01 schrieb Christoph Hellwig:
> On Mon, Jun 14, 2010 at 11:11:20PM +0200, Dan Carpenter wrote:
> > > Looks like you've applied the patch to a far too old kernel. It can't
> > > be NULL for quite a while already.
> >
> > You're the expert, but it looks like it could b
Am Samstag 29 Mai 2010, 11:49:07 schrieb Dan Carpenter:
> The "file" argument for fsync is never null so we can remove this check.
>
> What drew my attention here is that 7ea8085910e: "drop unused dentry
> argument to ->fsync" introduced an unconditional dereference at the
> start of the function
Am Sonntag 10 Januar 2010 21:05:46 schrieb Johannes Hirte:
> I've observed this hanging task now several times. Not sure when this
> started, but 2.6.32 is affected too, IIRC. I don't have a test pattern for
> this. Dovecot imap triggers this from time to
Am Donnerstag 14 Januar 2010 20:37:08 schrieb Chris Mason:
> On Thu, Jan 07, 2010 at 10:29:32PM +0100, Johannes Hirte wrote:
> > One of my btrfs filesystems gives the following bug message on access:
> >
> > Jan 6 23:08:12 datengrab kernel: [ cut here ]
Am Donnerstag 07 Januar 2010 22:29:32 schrieb Johannes Hirte:
> One of my btrfs filesystems gives the following bug message on access:
>
> Jan 6 23:08:12 datengrab kernel: [ cut here ]
> Jan 6 23:08:12 datengrab kernel: kernel BUG at
> include/linux/spin
Am Sonntag 10 Januar 2010 21:19:26 schrieb Chris Mason:
> On Sun, Jan 10, 2010 at 09:05:46PM +0100, Johannes Hirte wrote:
> > I've observed this hanging task now several times. Not sure when this
> > started, but 2.6.32 is affected too, IIRC. I don't have a test pattern
&
I've observed this hanging task now several times. Not sure when this started,
but 2.6.32 is affected too, IIRC. I don't have a test pattern for this. Dovecot
imap triggers this from time to time. I've enabled CONFIG_DETECT_HUNG_TASK now
and got this two tasks which hang:
INFO: task imap:2958 b
Am Samstag 09 Januar 2010 12:05:34 schrieb Goffredo Baroncelli:
> Hi Michael
>
> On Saturday 09 January 2010, Dipl.-Ing. Michael Niederle wrote:
> > Thanks for the quick reply!
> >
> > But I still have problems with btrfsctl:
> > > stat /dev/btrfs-control
> > >
> > File: `/dev/btrfs-control'
>
One of my btrfs filesystems gives the following bug message on access:
Jan 6 23:08:12 datengrab kernel: [ cut here ]
Jan 6 23:08:12 datengrab kernel: kernel BUG at include/linux/spinlock.h:376!
Jan 6 23:08:12 datengrab kernel: invalid opcode: [#1] SMP
Jan 6 23:08:1
the case:
> >
> > On Wed, 2010-01-06 at 18:24 +0100, Johannes Hirte wrote:
> >> Am Mittwoch 06 Januar 2010 16:59:55 schrieb Steve Freitas:
> >>> So please correct me if I have some mistaken assumptions. I thought
> >>> btrfs would be tolerant of that -
Am Mittwoch 06 Januar 2010 16:59:55 schrieb Steve Freitas:
> Hi Sander,
>
> On Wed, 2010-01-06 at 08:52 +0100, Sander wrote:
> > I don't have your original mail, but I think I remember you mentioned a
> > lot of bad sectors on that disk reported by SMART.
> >
> > If that is indeed the case it migh
Check for for NULL pointer in btrfs_set_acl and omit calling
posix_acl_equiv_mode in this case to avoid NULL pointer dereference there.
Signed-off-by: Johannes Hirte
diff --git a/fs/btrfs/acl.c b/fs/btrfs/acl.c
index 2e9e699..3a3a96d 100644
--- a/fs/btrfs/acl.c
+++ b/fs/btrfs/acl.c
@@ -111,13
Am Samstag 02 Januar 2010 23:34:17 schrieb Carlos R. Mafra:
> On Sa 2.Jan'10 at 11:32:27 +0100, Carlos R. Mafra wrote:
> > I started testing btrfs for my /home a few days ago and yesterday
> > I hit a kernel bug, using 2.6.33-rc2-00187-g08d869a.
> >
> > I wasn't doing any stress test with it, I wa
Am Mittwoch 18 November 2009 22:28:27 schrieb briaeros007:
> Hello,
> For some days, i've got oops on my system and i've investigate it a bit.
> The trouble was with "posix_acl_equiv_mode" , and for some reason
> (corrupted metadata ?) btrfs sometimes call it with "acl"==NULL
> This function doesn
Am Freitag 11 Dezember 2009 16:27:54 schrieb Edward Shishkin:
> Johannes Hirte wrote:
> > Am Freitag 11 Dezember 2009 12:17:29 schrieb Edward Shishkin:
> >> Johannes Hirte wrote:
> >>> Am Freitag 11 Dezember 2009 00:15:46 schrieb Johannes Hirte:
> >>>>
Am Freitag 11 Dezember 2009 12:17:29 schrieb Edward Shishkin:
> Johannes Hirte wrote:
> > Am Freitag 11 Dezember 2009 00:15:46 schrieb Johannes Hirte:
> >
> >> Am Freitag 25 September 2009 00:06:23 schrieb Edward Shishkin:
> &
Am Freitag 11 Dezember 2009 00:15:46 schrieb Johannes Hirte:
> Am Freitag 25 September 2009 00:06:23 schrieb Edward Shishkin:
> > Hello everyone.
>
> ...
>
> > The following patches are for Fedora 10(**).
> > The distro-independent package will be put to kernel.or
Am Dienstag 03 November 2009 01:59:39 schrieb Edward Shishkin:
> Johannes Hirte wrote:
> > Why is the btrfs code
> > dealing with network devices at all?
>
> Why not? :)
I don't see the possiblity to get a btrfs filesystem this way. So as far as I
understand this, it&
Am Freitag 25 September 2009 00:06:23 schrieb Edward Shishkin:
> Hello everyone.
...
> The following patches are for Fedora 10(**).
> The distro-independent package will be put to kernel.org a bit later.
>
>
> All comments, bugreports, etc. are welcome as usual.
Ok, I have another comment/bugre
Am Mittwoch 18 November 2009 22:28:27 schrieb briaeros007:
> Hello,
> For some days, i've got oops on my system and i've investigate it a bit.
> The trouble was with "posix_acl_equiv_mode" , and for some reason
> (corrupted metadata ?) btrfs sometimes call it with "acl"==NULL
> This function doesn
1 - 100 of 110 matches
Mail list logo
