I just tried running btrsfck without enough right to open the device, i got the
same : a segfault. I also got the segfault taking a unknow device.
Please display a message like : "Unknow device or file, you may not have enough
rights to open it"
--
To unsubscribe from this list: send the line "un
On Wed, Apr 29, 2009 at 02:40:19PM -0400, Chris Mason spake thusly:
> Well, then I'm surprised btrfs doesn't crash more violently and more
> often ;)
Note that this will be a problem that btrfs must properly manage. And
it must be done MUCH better than a certain previously semi-popular
filesystem
> Do you think you're hitting a memtest bug or is the HW really bad?
If you can stomach it, you can get a second opinion from the bootable
windows memory testing iso:
http://oca.microsoft.com/en/windiag.asp
- z
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the b
Zach Brown wrote:
>> Do you think you're hitting a memtest bug or is the HW really bad?
>
> If you can stomach it, you can get a second opinion from the bootable
> windows memory testing iso:
>
> http://oca.microsoft.com/en/windiag.asp
>
> - z
It will be hard but I might just try it. Two v
To be honest I have no idea. Let me see if I can find a different
version to test with and see. I think I'm still under warranty. ;)
Chris Mason wrote:
> On Wed, 2009-04-29 at 14:38 -0400, Marc R. O'Connor wrote:
I have done that on all btrfs partitions I have and btrfsck did not
return
On Wed, 2009-04-29 at 14:38 -0400, Marc R. O'Connor wrote:
> >
> >> I have done that on all btrfs partitions I have and btrfsck did not
> >> return anything odd.
> >>
> >
> > In that case, the bad ordering is being introduced at run time. Could
> > you please run memtest86 on the box?
> >
> > -
Chris Mason wrote:
> On Wed, 2009-04-29 at 14:21 -0400, Marc R. O'Connor wrote:
>> Chris Mason wrote:
>>> On Wed, 2009-04-29 at 12:04 -0400, Marc R. O'Connor wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
full file-item.c attached
Chris Mason wrote:
> On Tu
On Wed, 2009-04-29 at 14:21 -0400, Marc R. O'Connor wrote:
>
> Chris Mason wrote:
> > On Wed, 2009-04-29 at 12:04 -0400, Marc R. O'Connor wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> full file-item.c attached
> >>
> >> Chris Mason wrote:
> >>> On Tue, 2009-04-28 at 13:3
Chris Mason wrote:
> On Wed, 2009-04-29 at 12:04 -0400, Marc R. O'Connor wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> full file-item.c attached
>>
>> Chris Mason wrote:
>>> On Tue, 2009-04-28 at 13:39 -0400, Marc R. O'Connor wrote:
I have had two 'kernel bug' issues today
On Wed, 2009-04-29 at 12:04 -0400, Marc R. O'Connor wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> full file-item.c attached
>
> Chris Mason wrote:
> > On Tue, 2009-04-28 at 13:39 -0400, Marc R. O'Connor wrote:
> >> I have had two 'kernel bug' issues today both referencing file-item
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
full file-item.c attached
Chris Mason wrote:
> On Tue, 2009-04-28 at 13:39 -0400, Marc R. O'Connor wrote:
>> I have had two 'kernel bug' issues today both referencing file-item.c.
>> The first oops happened when i was cp'ing from and external HD(ext3)
On Wed, 2009-04-29 at 17:26 +0200, Thomas Glanzmann wrote:
> Hello Chris,
>
> > Your database should know, and the ioctl could check to see if the
> > source and destination already point to the same thing before doing
> > anything expensive.
>
> I see.
>
> > > So, if I only have file, offset, l
Hello Chris,
> Your database should know, and the ioctl could check to see if the
> source and destination already point to the same thing before doing
> anything expensive.
I see.
> > So, if I only have file, offset, len and not the block number, is there
> > a way from userland to tell if two
On Wed, 2009-04-29 at 15:58 +0200, Thomas Glanzmann wrote:
> Hello Chris,
>
> > But, in your ioctls you want to deal with [file, offset, len], not
> > directly with block numbers. COW means that blocks can move around
> > without you knowing, and some of the btrfs internals will COW files in
> >
Hello Chris,
> But, in your ioctls you want to deal with [file, offset, len], not
> directly with block numbers. COW means that blocks can move around
> without you knowing, and some of the btrfs internals will COW files in
> order to relocate storage.
> So, what you want is a dedup file (or fil
On Wed, 2009-04-29 at 14:03 +0200, Thomas Glanzmann wrote:
> Hello Chris,
>
> > You can start with the code documentation section on
> > http://btrfs.wiki.kernel.org
>
> I read through this and at the moment one questions come in my mind:
>
> http://btrfs.wiki.kernel.org/images-btrfs/7/72/Chunks
Thomas Glanzmann wrote:
Looking at this picture, when I'm going to implement the dedup code, do I also
have to take care to spread the blocks over the different devices or is
there already infrastructure in place that automates that process?
If you somehow had blocks duplicated exactly across t
Hello Chris,
> You can start with the code documentation section on
> http://btrfs.wiki.kernel.org
I read through this and at the moment one questions come in my mind:
http://btrfs.wiki.kernel.org/images-btrfs/7/72/Chunks-overview.png
Looking at this picture, when I'm going to implement the ded
On Wed, Apr 29, 2009 at 07:40:22PM +0800, Chris Mason wrote:
> On Wed, 2009-04-29 at 16:21 +0800, Wu Fengguang wrote:
> > On Wed, Apr 29, 2009 at 04:16:16PM +0800, Wu Fengguang wrote:
> > > On Thu, Apr 09, 2009 at 10:37:39AM -0400, Chris Mason wrote:
> > [snip]
> > > > PagePrivate is very common.
On Wed, 2009-04-29 at 16:21 +0800, Wu Fengguang wrote:
> On Wed, Apr 29, 2009 at 04:16:16PM +0800, Wu Fengguang wrote:
> > On Thu, Apr 09, 2009 at 10:37:39AM -0400, Chris Mason wrote:
> [snip]
> > > PagePrivate is very common. try_to_releasepage failing on a clean page
> > > without the writeback
On Wed, Apr 29, 2009 at 04:16:16PM +0800, Wu Fengguang wrote:
> On Thu, Apr 09, 2009 at 10:37:39AM -0400, Chris Mason wrote:
[snip]
> > PagePrivate is very common. try_to_releasepage failing on a clean page
> > without the writeback bit set and without dirty/locked buffers will be
> > pretty rare.
21 matches
Mail list logo
