On 09/29/2010 09:19 AM, Lennart Poettering wrote:
On Tue, 28.09.10 20:08, Josef Bacik (jo...@redhat.com) wrote:
On Tue, Sep 28, 2010 at 07:25:13PM -0400, Christoph Hellwig wrote:
On Tue, Sep 28, 2010 at 04:53:16PM -0400, Josef Bacik wrote:
This was a request from the systemd guys. They need
On Wed, Sep 29, 2010 at 09:25, Ric Wheeler wrote:
> Second question is why is checking in /sys a big deal, would you prefer an
> interface like we did for alignment in libblkid?
It's about knowing what's behind the 'nodev' major == 0 of a btrfs
mount. There is no way to get that from /sys or an
Here is the patch that I already proposed a while ago. I've tested
xfstests on btrfs and xfstests to make sure the btrfs issue is fixed,
and I've also tested the original dirtying of device files issue
and I/O operations on block device files to test the special case
in the patch.
---
From: Chris
Hey guys,
Today I experienced my first checksum error just out of the blue - and
it's not just the 'csum + 1 = private' issue, it's a completely
different one. Because of this, I am unable to retrieve the data off
the drive, even with nodatasum enabled - I simply get an I/O error.
Here's the dmesg
On Wed, Sep 29, 2010 at 12:48, Sebastian 'gonX' Jensen
wrote:
> Hey guys,
>
> Today I experienced my first checksum error just out of the blue - and
> it's not just the 'csum + 1 = private' issue, it's a completely
> different one. Because of this, I am unable to retrieve the data off
> the drive,
On 29 September 2010 13:12, Francis Galiegue wrote:
> On Wed, Sep 29, 2010 at 12:48, Sebastian 'gonX' Jensen
> wrote:
>> Hey guys,
>>
>> Today I experienced my first checksum error just out of the blue - and
>> it's not just the 'csum + 1 = private' issue, it's a completely
>> different one. Beca
On Wed, 29.09.10 16:25, Ric Wheeler (rwhee...@redhat.com) wrote:
> >This in fact is how all current readahead implementations work, be it
> >the fedora, the suse or ubuntu's readahead or Arjan's sreadahead. What's
> >new is that in the systemd case we try to test for ssd/rotating
> >properly, inst
On 09/29/2010 08:59 PM, Lennart Poettering wrote:
On Wed, 29.09.10 16:25, Ric Wheeler (rwhee...@redhat.com) wrote:
This in fact is how all current readahead implementations work, be it
the fedora, the suse or ubuntu's readahead or Arjan's sreadahead. What's
new is that in the systemd case we t
On Wed 29-09-10 10:19:36, Christoph Hellwig wrote:
> ---
> From: Christoph Hellwig
> Subject: [PATCH] writeback: always use sb->s_bdi for writeback purposes
>
...
> The one exception for now is the block device filesystem which really
> wants different writeback contexts for it's different (inter
On Wed, Sep 29, 2010 at 01:25, Christoph Hellwig wrote:
> On Tue, Sep 28, 2010 at 04:53:16PM -0400, Josef Bacik wrote:
>> This was a request from the systemd guys. They need a quick and easy way to
>> get
>> all devices attached to a Btrfs filesystem in order to check if any of the
>> disks
>>
On Wed, Sep 29, 2010 at 13:37, Sebastian 'gonX' Jensen
wrote:
[...]
>>
>> Which kernel is that?
> It was one of the 2.6.35 versions from the Ubuntu repository. I'm
> running Ubuntu 10.04 Server.
>
Since 2.6.32 works, you should report that bug to Ubuntu.
The upstream commit is f281fb5fe54e15a7ab
On Tue 28-09-10 10:05:49, Artem Bityutskiy wrote:
> On Mon, 2010-09-27 at 18:54 -0400, Chris Mason wrote:
> > On Tue, Sep 28, 2010 at 12:25:48AM +0200, Jan Kara wrote:
> > > [Added CCs for similar ecryptfs warning]
> > > On Thu 23-09-10 12:38:49, Andrew Morton wrote:
> > > > > This started appearin
On Mon 27-09-10 20:55:45, Cesar Eduardo Barros wrote:
> Em 27-09-2010 19:25, Jan Kara escreveu:
> >[Added CCs for similar ecryptfs warning]
> >On Thu 23-09-10 12:38:49, Andrew Morton wrote:
> >>>[...]
> >>>device fsid 44d595920ddedfa-3ece6b56e80f689e devid 1 transid 22342
> >>>/dev/mapper/vg_cesarb
>>> Which kernel is that?
>> It was one of the 2.6.35 versions from the Ubuntu repository. I'm
>> running Ubuntu 10.04 Server.
>>
>
> Since 2.6.32 works, you should report that bug to Ubuntu.
Alternatively, retest using ubuntu's mainline kernel ppa
(http://kernel.ubuntu.com/~kernel-ppa/mainline/),
On Wed, 2010-09-29 at 15:00 +0200, Jan Kara wrote:
> On Tue 28-09-10 10:05:49, Artem Bityutskiy wrote:
> > On Mon, 2010-09-27 at 18:54 -0400, Chris Mason wrote:
> > > On Tue, Sep 28, 2010 at 12:25:48AM +0200, Jan Kara wrote:
> > > > [Added CCs for similar ecryptfs warning]
> > > > On Thu 23-09-10 1
On Wed, Sep 29, 2010 at 02:18:08PM +0200, Jan Kara wrote:
> On Wed 29-09-10 10:19:36, Christoph Hellwig wrote:
> > ---
> > From: Christoph Hellwig
> > Subject: [PATCH] writeback: always use sb->s_bdi for writeback purposes
> >
> ...
> > The one exception for now is the block device filesystem whi
On 29 September 2010 15:15, cwillu wrote:
Which kernel is that?
>>> It was one of the 2.6.35 versions from the Ubuntu repository. I'm
>>> running Ubuntu 10.04 Server.
>>>
>>
>> Since 2.6.32 works, you should report that bug to Ubuntu.
>
> Alternatively, retest using ubuntu's mainline kernel p
On Wed, Sep 29, 2010 at 8:31 AM, Sebastian 'gonX' Jensen
wrote:
> On 29 September 2010 15:15, cwillu wrote:
> Which kernel is that?
It was one of the 2.6.35 versions from the Ubuntu repository. I'm
running Ubuntu 10.04 Server.
>>>
>>> Since 2.6.32 works, you should report that
On 9/28/10 11:47 , Francis Galiegue wrote:
As to file system hardening, what do you mean apart from checksums?
Fundamental filesystem design?
I specifically mean the intended ability to survive a power failure.
Historically, unix file systems lived in the disk cache such that a
power failure
The new ENOSPC stuff broke the df ioctl since we no longer create seperate space
info's for each RAID type. So instead, loop through each space info's raid
lists so we can get the right RAID information which will allow the df ioctl to
tell us RAID types again. Thanks,
Signed-off-by: Josef Bacik
Hi,
I know BTRFS is a kind of Log-structured File System, which doesn't do
overwrite. Here is my question, suppose file A is overwritten by A',
instead of writing A' to the original place of A, a new place is
selected to store it. However, we know that the address of a file
should be recorded in i
On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
> I know BTRFS is a kind of Log-structured File System, which doesn't do
> overwrite. Here is my question, suppose file A is overwritten by A',
> instead of writing A' to the original place of A, a new place is
> selected to store it. Howev
Sebastian 'gonX' Jensen, Wed, 29 Sep 2010 12:48:56 +0200:
> Hey guys,
>
> Today I experienced my first checksum error just out of the blue - and
> it's not just the 'csum + 1 = private' issue, it's a completely
> different one. Because of this, I am unable to retrieve the data off the
> drive, ev
On 29 September 2010 19:35, Lubos Kolouch wrote:
> Sebastian 'gonX' Jensen, Wed, 29 Sep 2010 12:48:56 +0200:
>
>> Hey guys,
>>
>> Today I experienced my first checksum error just out of the blue - and
>> it's not just the 'csum + 1 = private' issue, it's a completely
>> different one. Because of t
Hi,
On Wed, Sep 29, 2010 at 11:37 AM, Dipl.-Ing. Michael Niederle
wrote:
> Hi Yuehai!
>
> I tested nilfs2 and btrfs for the use with flash based pen drives.
>
> nilfs2 performed incredibly well as long as there were enough free blocks. But
> the garbage collector of nilfs used too much IO-bandwid
On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell wrote:
> On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
>> I know BTRFS is a kind of Log-structured File System, which doesn't do
>> overwrite. Here is my question, suppose file A is overwritten by A',
>> instead of writing A' to the origin
On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell wrote:
> In btrfs, this is solved by doing the same thing for the inode--a new
> place for the leaf holding the inode is chosen. Then the parent of the
> leaf must point to the new position of the leaf, so the parent is moved,
> and the parent's parent
On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote:
> On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell
> wrote:
> > On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
> >> I know BTRFS is a kind of Log-structured File System, which doesn't do
> >> overwrite. Here is my question, suppo
On Wed, Sep 29, 2010 at 03:39:07PM -0400, Aryeh Gregor wrote:
> On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell
> wrote:
> > In btrfs, this is solved by doing the same thing for the inode--a new
> > place for the leaf holding the inode is chosen. Then the parent of the
> > leaf must point to the ne
Don't dereference em if it's NULL or an error pointer.
Signed-off-by: Roel Kluin
---
I just noticed this by code analysis. It wasn't tested in any way.
fs/btrfs/inode.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index c038644..
On Wed, Sep 29, 2010 at 3:59 PM, Sean Bartell wrote:
> On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote:
>> On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell
>> wrote:
>> > On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
>> >> I know BTRFS is a kind of Log-structured File System,
On Wed 29-09-10 16:10:06, Christoph Hellwig wrote:
> On Wed, Sep 29, 2010 at 02:18:08PM +0200, Jan Kara wrote:
> > On Wed 29-09-10 10:19:36, Christoph Hellwig wrote:
> > > ---
> > > From: Christoph Hellwig
> > > Subject: [PATCH] writeback: always use sb->s_bdi for writeback purposes
> > >
> > ...
On Wed, Sep 29, 2010 at 10:04:31AM +0200, Kay Sievers wrote:
> On Wed, Sep 29, 2010 at 09:25, Ric Wheeler wrote:
>
> > Second question is why is checking in /sys a big deal, would ??you prefer an
> > interface like we did for alignment in libblkid?
>
> It's about knowing what's behind the 'nodev
On Thu, Sep 30, 2010 at 01:38:07AM +0200, Jan Kara wrote:
> > No. For one thing we don't need any exception for correctnes alone -
> > even the block device variant would work fine with the default case.
> Here I don't agree. If you don't have some kind of exception, sb->s_bdi
> for both "block" a
On Wed, Sep 29, 2010 at 07:43:27PM -0400, Christoph Hellwig wrote:
> On Wed, Sep 29, 2010 at 10:04:31AM +0200, Kay Sievers wrote:
> > On Wed, Sep 29, 2010 at 09:25, Ric Wheeler wrote:
> >
> > > Second question is why is checking in /sys a big deal, would ??you prefer
> > > an
> > > interface lik
Just curious...
I've been wondering if it would possible/useful to make a btrfs mode
where it _always_ writes in a ring on the entire disk. Since it can
write "anywhere" already, it could just write sequentially always.
The write process would have to be changed to read a blob, throw away
the ga
36 matches
Mail list logo
