I have sent my test case to xfs mailing list (No. 248).
Please help to review it. Thanks!
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Wednesday, December 08, 2010 12:55 AM
To: Zhong, Xin
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: pwrite b
> After creating snapshot 10 from snapshot 9, snapshot 6 vanished from
> the output of "btrfs subvolume list /dev/sdf1":
>
> # btrfs subv list /mnt/sdf1
> ID 256 top level 5 path snap01
> ID 257 top level 5 path snap02
> ID 258 top level 5 path snap03
> ID 259 top l
On 12/13/2010 05:11 AM, Sander wrote:
Gordan Bobic wrote (ao):
On 12/12/2010 17:24, Paddy Steed wrote:
In a few weeks parts for my new computer will be arriving. The storage
will be a 128GB SSD. A few weeks after that I will order three large
disks for a RAID array. I understand that BTRFS RAID
The keys returned by tree search ioctl should be restricted to:
key.objectid = [min_objectid, max_objectid] &&
key.offset = [min_offset, max_offset] &&
key.type = [min_type, max_type]
But actually it returns those keys:
[(min_objectid, min_type, min_offset),
We check if num_found >= sk->nr_items every time we find an
expected item, but num_found is not incremented, so we may
return items more than the user asked.
Also return -EINVAL if the user specified 0 nr_items.
Signed-off-by: Li Zefan
---
fs/btrfs/ioctl.c |7 ---
1 files changed, 4 ins
- Check if the key is within specified range before checking the
item length.
- Advance to the next key a bit more efficiently.
- Remove redundant code.
Signed-off-by: Li Zefan
---
fs/btrfs/ioctl.c | 30 --
1 files changed, 12 insertions(+), 18 deletions(-)
diff
Hello.
Sorry if it's already fixed, but with 2.6.35.6-48.fc14.x86_64, when I
do btrfs device delete /dev/blabla /btrfs kernel moves everything
except 1 gigabyte off the device, but then fails to remove it, saying
"btrfs: unable to remove the only writeable device" to dmesg.
What's even more inter
On Mon, Dec 13, 2010 at 4:25 AM, Gordan Bobic wrote:
> I suggest you back your opinion up with some hard data before making such
> statements. Here's a quick test - make an ext2 fs and a btrfs on two similar
> disk partitions (any disk, for the sake of the experiment it doesn't have to
> be an ssd)
On 13/12/2010 14:33, Peter Harris wrote:
On Mon, Dec 13, 2010 at 4:25 AM, Gordan Bobic wrote:
I suggest you back your opinion up with some hard data before making such
statements. Here's a quick test - make an ext2 fs and a btrfs on two similar
disk partitions (any disk, for the sake of the expe
On Mon, Dec 13, 2010 at 3:25 AM, Gordan Bobic wrote:
> On 12/13/2010 05:11 AM, Sander wrote:
>>
>> Gordan Bobic wrote (ao):
>>>
>>> On 12/12/2010 17:24, Paddy Steed wrote:
In a few weeks parts for my new computer will be arriving. The storage
will be a 128GB SSD. A few weeks after t
On 13/12/2010 15:17, cwillu wrote:
In a few weeks parts for my new computer will be arriving. The storage
will be a 128GB SSD. A few weeks after that I will order three large
disks for a RAID array. I understand that BTRFS RAID 5 support will be
available shortly. What is the best possible way f
Thank you for all your replies.
On Mon, 2010-12-13 at 00:04 +, Gordan Bobic wrote:
> On 12/12/2010 17:24, Paddy Steed wrote:
> > In a few weeks parts for my new computer will be arriving. The storage
> > will be a 128GB SSD. A few weeks after that I will order three large
> > disks for a RAID
On 13/12/2010 17:17, Paddy Steed wrote:
So, no-one has any idea's on how to implement the cache. Would making it
all swap work, does to OS cache files in swap?
No, it doesn't. I don't believe there are any plans to implement
hierarchical storage in BTRFS, but perhaps one of the developers can
Hi Li,
On Monday, 13 December, 2010, Li Zefan wrote:
> The keys returned by tree search ioctl should be restricted to:
>
> key.objectid = [min_objectid, max_objectid] &&
> key.offset = [min_offset, max_offset] &&
> key.type = [min_type, max_type]
>
> But actually it retur
On Mon, Dec 13, 2010 at 05:17:51PM +, Paddy Steed wrote:
> So, no-one has any idea's on how to implement the cache. Would making it
> all swap work, does to OS cache files in swap?
Quite the opposite. Too many people have ideas for SSD-as-cache in Linux,
in non particular order:
— bcache
—
On Sun, Dec 12, 2010 at 8:06 PM, Ted Ts'o wrote:
> On Sun, Dec 12, 2010 at 07:11:28AM -0600, Jon Nelson wrote:
>> I'm glad you've been able to reproduce the problem! If you should need
>> any further assistance, please do not hesitate to ask.
>
> This patch seems to fix the problem for me. (Unles
On 12/13/2010 01:20 PM, Tomasz Torcz wrote:
On Mon, Dec 13, 2010 at 05:17:51PM +, Paddy Steed wrote:
So, no-one has any idea's on how to implement the cache. Would making it
all swap work, does to OS cache files in swap?
Quite the opposite. Too many people have ideas for SSD-as-cache in
On Mon, 13 Dec 2010 15:22:10 +0800
Shaohua Li wrote:
> Add an ioctl to dump filesystem's metadata in memory in vfs. Userspace
> collects
> such info and uses it to do metadata readahead.
> Filesystem can hook to super_operations.metadata_incore to get metadata in
> specific approach. Next patch
On Mon, 13 Dec 2010 15:22:11 +0800
Shaohua Li wrote:
> Implement btrfs specific .metadata_incore.
> In btrfs, all metadata pages are in a special btree_inode, we take pages from
> it.
> we only account updated and referenced pages here. Say we collect metadata
> info
> in one boot, do metadata
On Mon, 13 Dec 2010 15:22:14 +0800
Shaohua Li wrote:
> Add metadata readahead ioctl in vfs. Filesystem can hook to
> super_operations.metadata_readahead to handle filesystem specific task.
> Next patch will give an example how btrfs implements it.
>
> Signed-off-by: Shaohua Li
>
> ---
> fs/co
On Mon, Dec 13, 2010 at 3:22 PM, Shaohua Li wrote:
> Implementation btrfs .metadata_readahead. In btrfs, all metadata pages are in
> a
> special btree_inode. We do readahead in it.
>
> Signed-off-by: Shaohua Li
>
> ---
> fs/btrfs/disk-io.c | 10 ++
> fs/btrfs/super.c | 13
On Tue, 2010-12-14 at 08:40 +0800, Andrew Morton wrote:
> On Mon, 13 Dec 2010 15:22:10 +0800
> Shaohua Li wrote:
>
> > Add an ioctl to dump filesystem's metadata in memory in vfs. Userspace
> > collects
> > such info and uses it to do metadata readahead.
> > Filesystem can hook to super_operatio
On Tue, 2010-12-14 at 09:06 +0800, Yan, Zheng wrote:
> On Mon, Dec 13, 2010 at 3:22 PM, Shaohua Li wrote:
> > Implementation btrfs .metadata_readahead. In btrfs, all metadata pages are
> > in a
> > special btree_inode. We do readahead in it.
> >
> > Signed-off-by: Shaohua Li
> >
> > ---
> > fs/
Excerpts from Yan, Zheng's message of 2010-11-16 20:38:23 -0500:
> On Wed, Nov 17, 2010 at 5:22 AM, Josef Bacik wrote:
> > There is a bug in find_free_extent where if we don't find a free extent in
> > the
> > raid type we are looking for, we loop through to the next raid type. This
> > is
> >
Excerpts from Zhong, Xin's message of 2010-12-13 03:26:04 -0500:
> I have sent my test case to xfs mailing list (No. 248).
> Please help to review it. Thanks!
You btrfs patch is now in the master branch of the btrfs unstable tree.
Thanks!
-chris
--
To unsubscribe from this list: send the line "u
On Tue, Dec 14, 2010 at 9:33 AM, Chris Mason wrote:
> Excerpts from Yan, Zheng's message of 2010-11-16 20:38:23 -0500:
>> On Wed, Nov 17, 2010 at 5:22 AM, Josef Bacik wrote:
>> > There is a bug in find_free_extent where if we don't find a free extent in
>> > the
>> > raid type we are looking for
Hi everyone,
The master branch of the btrfs unstable tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git master
Has an assortment of bug fixes. It includes some corruption fixes when
mounting the filesystem in degraded mode, and related oopsen as we try
to mount damaged
Excerpts from Yan, Zheng's message of 2010-12-13 20:54:12 -0500:
> On Tue, Dec 14, 2010 at 9:33 AM, Chris Mason wrote:
> > Excerpts from Yan, Zheng's message of 2010-11-16 20:38:23 -0500:
> >> On Wed, Nov 17, 2010 at 5:22 AM, Josef Bacik wrote:
> >> > There is a bug in find_free_extent where if w
I can reliably get btrfs 0.19 to hang in btrfs_commit_transaction.
Below is another case where it hung after creating just 110 snapshots
of /var/log/. Here is an excerpt from the script log file showing the
last good snapshot followed by the hang:
>>> Dec 12 10:25:23 EST 2010 snapshot /mnt/sdf1/s
Chris, thanks a lot for your quick response.
Thanks to Zheng Yan too for his careful review.
-Original Message-
From: Chris Mason [mailto:chris.ma...@oracle.com]
Sent: Tuesday, December 14, 2010 9:36 AM
To: Zhong, Xin
Cc: Christoph Hellwig; linux-btrfs@vger.kernel.org
Subject: RE: [PATCH
Goffredo Baroncelli wrote:
> Hi Li,
>
> On Monday, 13 December, 2010, Li Zefan wrote:
>> The keys returned by tree search ioctl should be restricted to:
>>
>> key.objectid = [min_objectid, max_objectid] &&
>> key.offset = [min_offset, max_offset] &&
>> key.type = [min_type, ma
31 matches
Mail list logo