On Thu, 27 Sep 2012 23:02:35 +0200
Goffredo Baroncelli wrote:
> Sorry for the space error:
> Below a more correct example
>
> $ btrfs filesystem disk-free /
> Summary:
> Total:135.00GB
> Allocated: 10.51GB
> Unallocated: 124.49
From: Robin Dong
Using mkfs.btrfs like:
mkfs.btrfs -b 1048576 /dev/sda
will report error:
mkfs.btrfs: volumes.c:796: btrfs_alloc_chunk: Assertion `!(ret)' failed.
Aborted
because the length of dev_extent is 4MB.
But if we use mkfs.btrfs with 8MB total bytes, the newly
From: Robin Dong
Using mkfs.btrfs like:
mkfs.btrfs -l 131072 /dev/sda
will return no error, but after mount it, the dmesg will report:
BTRFS: couldn't mount because metadata blocksize (131072) was too large
The leafsize and nodesize are equal at present, so we just use one fun
On thu, 27 Sep 2012 19:56:24 +0300, Ilya Dryomov wrote:
>> the parameters are right. So besides the code cleanup, this patch also
>> add a check for the usage of the space balance, it is the only place that
>> we need add check to make sure the parameters of div_factor are right till
>> now. Beside
div_factor{_fine} has been implemented for two times, and these two functions
are very similar, so cleanup the reduplicate implement and drop the original
div_factor(), and then rename div_factor_fine() to div_factor(). So the factor
of the new div_factor() is 100, not 10.
And I move div_factor in
On Thu, Sep 27, 2012 at 6:02 PM, Alfredo Esteban wrote:
> Hello,
>
> I'm sending a patch to show progress of btrfs-convert command. I put a
> progress bar in the only heavy process: the btrfs metadata creation
> (due to CRC calculation):
Please include patches inline in the email, not as an attac
Hello,
I'm sending a patch to show progress of btrfs-convert command. I put a
progress bar in the only heavy process: the btrfs metadata creation
(due to CRC calculation):
> ./btrfs-convert /dev/loop1
Creating btrfs metadata [] 100%
Creating ext2fs
Everytime we write out dirty pages we search for an offset in the tree,
convert the bits in the state, and then when we wait we search for the
offset again and clear the bits. So for every dirty range in the io tree we
are doing 4 rb searches, which is suboptimal. With this patch we are only
doin
On 09/27/2012 12:44 PM, Sébastien Maury wrote:
Hi,
I've installed a new server using btrfs for my root partition ("/").
It uses snapper for snapshots management and all seems to work pretty fine.
My problem is to be able to know the remaining REAL free space in my
partition.
Using different c
On Tue, Sep 25, 2012 at 04:04:46PM -0400, Chris Mason wrote:
> On Mon, Aug 20, 2012 at 02:29:17PM -0600, Mark Fasheh wrote:
> >
> > Testing wise, the basic namespace operations work well (link, unlink, etc).
> > The rest has gotten less debugging (and I really don't have a great way of
> > testing
Hi Jan,
I hope to get my proposal working soon, then expect for some code from
me to look at.
Thanks!
Alex.
On Mon, Sep 24, 2012 at 11:27 AM, Jan Schmidt wrote:
> Hi Alex,
>
> On Mon, September 24, 2012 at 11:13 (+0200), Alex Lyakas wrote:
>> Hi,
>>
>>> write_buf:
>>> Used to write the stream t
Hi Miao,
You haven't addressed any of my concerns with v3.
On Thu, Sep 27, 2012 at 06:19:58PM +0800, Miao Xie wrote:
(snipped)
> the parameters are right. So besides the code cleanup, this patch also
> add a check for the usage of the space balance, it is the only place that
> we need add check
On Thu, Sep 27, 2012 at 03:09:15AM -0600, Miao Xie wrote:
> According to the comment, we can overcommit the space up to 1/2 of the total
> disk space, or we just can overcommit up to 1/8. But the code was written
> reversedly. Fix it.
>
Sorry the comment is wrong, I was actually just looking at t
Please ignore this patch, it is not based on the new btrfs-next tree.
I'll send the right one as soon as possible.
Thanks
Miao
On thu, 27 Sep 2012 17:09:15 +0800, Miao Xie wrote:
> According to the comment, we can overcommit the space up to 1/2 of the total
> disk space, or we just can overcommit
Hi,
Thanks a lot for your time and answers.
Things look pretty clear now for me.
I'm monitoring my systems using nagios, and i was annoyed about the
disk usage monitoring.
Thanks to your answers, i should be able to developp a rather accurate script.
Or so i hope :)
Regards,
Sebastien.
Hug
On Thu, Sep 27, 2012 at 01:25:58PM +0200, Sébastien Maury wrote:
> Hi,
>
> Thanks for the quick reply, this clarify me lots of things.
> I've had read the articles you mentioned, but i must admit that your
> explanations based on my examples makes things even more clearer.
>
> Also, if i unders
Please ignore this patch, my btrfs-next tree is old, and this patch will
conflict with Josef's patch
[PATCH] Btrfs: run delayed refs first when out of space
I will modify this patch as soon as possible.
Thanks
Miao
On thu, 27 Sep 2012 16:45:51 +0800, Miao Xie wrote:
> In some places(such as: ev
Hi,
Thanks for the quick reply, this clarify me lots of things.
I've had read the articles you mentioned, but i must admit that your
explanations based on my examples makes things even more clearer.
Also, if i understand things properly, snaphots size aren't included
in the "btrfs filesyste
On Thu, Sep 27, 2012 at 12:44:27PM +0200, Sébastien Maury wrote:
> I've installed a new server using btrfs for my root partition ("/").
>
> It uses snapper for snapshots management and all seems to work pretty fine.
>
> My problem is to be able to know the remaining REAL free space in my
> part
Sorry to reply late.
On Mon, 24 Sep 2012 18:47:42 +0200, David Sterba wrote:
>>> This is the most straightforward transformation I can think of. It
>>> doesn't result in an unnecessary BUG_ON, keeps churn to a minimum and
>>
>> agree with you.
>>
>>> doesn't change the "style" of the balance ioct
div_factor{_fine} has been implemented for two times, and these two functions
are very similar, so cleanup the reduplicate implement and drop the original
div_factor(), and then rename div_factor_fine() to div_factor(). So the factor
of the new div_factor() is 100, not 10.
And I move div_factor in
Hi,
I've installed a new server using btrfs for my root partition ("/").
It uses snapper for snapshots management and all seems to work pretty fine.
My problem is to be able to know the remaining REAL free space in my
partition.
Using different commands, i have different results, and i don'
On thu, 27 Sep 2012 16:45:51 +0800, Miao Xie wrote:
> In some places(such as: evicting inode), we just can not flush the reserved
> space of delalloc, flushing the delayed directory index and delayed inode
> is OK, but we don't try to flush those things and just go back when there is
> no enough sp
According to the comment, we can overcommit the space up to 1/2 of the total
disk space, or we just can overcommit up to 1/8. But the code was written
reversedly. Fix it.
Signed-off-by: Miao Xie
---
This is based on btrfs-next tree.
---
fs/btrfs/extent-tree.c |4 ++--
1 files changed, 2 inse
On Wed, Sep 26, 2012 at 03:52:07PM +0800, Robin Dong wrote:
> Using mkfs.btrfs like:
> mkfs.btrfs -l 131072 /dev/sda
>
> will return no error, but after mount it, the dmesg will report:
> BTRFS: couldn't mount because metadata blocksize (131072) was too large
>
> The user tools should
In some places(such as: evicting inode), we just can not flush the reserved
space of delalloc, flushing the delayed directory index and delayed inode
is OK, but we don't try to flush those things and just go back when there is
no enough space to be reserved. This patch fixes this problem.
We defin
On Tue, Sep 25, 2012 at 04:04:46PM -0400, Chris Mason wrote:
> @@ -889,16 +899,23 @@ static inline int __add_inode_ref(struct
> btrfs_trans_handle *trans,
> while (cur_offset < item_size) {
> extref = (struct btrfs_inode_extref *)base + cur_offset;
>
> -
On Thu, Sep 27, 2012 at 05:04:02AM +0800, ching wrote:
> On 09/26/2012 11:23 PM, David Sterba wrote:
> > On Wed, Sep 26, 2012 at 07:48:47PM +0800, ching wrote:
> >> There is a typo (?) in inode.c (git)
> > What's the top commit and what git tree?
> >
> > This has been fixed in 3.6-rc4 via
> > 28708
On Thu, Sep 27, 2012 at 3:05 PM, Dave Chinner wrote:
> On Thu, Sep 27, 2012 at 01:25:34PM +0800, Zhi Yong Wu wrote:
>> On Tue, Sep 25, 2012 at 5:28 PM, Dave Chinner wrote:
>> > On Sun, Sep 23, 2012 at 08:56:28PM +0800, zwu.ker...@gmail.com wrote:
>> >> From: Zhi Yong Wu
>> >>
>> >> Introduce o
On Thu, Sep 27, 2012 at 3:01 PM, Dave Chinner wrote:
> On Thu, Sep 27, 2012 at 02:54:22PM +0800, Zhi Yong Wu wrote:
>> On Thu, Sep 27, 2012 at 12:03 PM, Dave Chinner wrote:
>> > On Sun, Sep 23, 2012 at 08:56:32PM +0800, zwu.ker...@gmail.com wrote:
>> >> From: Zhi Yong Wu
>> >>
>> >> Fork and r
On Thu, Sep 27, 2012 at 2:59 PM, Dave Chinner wrote:
> On Thu, Sep 27, 2012 at 02:28:12PM +0800, Zhi Yong Wu wrote:
>> On Thu, Sep 27, 2012 at 11:54 AM, Dave Chinner wrote:
>> > On Sun, Sep 23, 2012 at 08:56:31PM +0800, zwu.ker...@gmail.com wrote:
>> >> From: Zhi Yong Wu
>> >>
>> >> Miscellane
On Thu, Sep 27, 2012 at 2:57 PM, Dave Chinner wrote:
> On Thu, Sep 27, 2012 at 02:23:16PM +0800, Zhi Yong Wu wrote:
>> On Thu, Sep 27, 2012 at 11:43 AM, Dave Chinner wrote:
>> > On Sun, Sep 23, 2012 at 08:56:30PM +0800, zwu.ker...@gmail.com wrote:
>> >> From: Zhi Yong Wu
>> >>
>> >> Adds a has
On Thu, Sep 27, 2012 at 01:25:34PM +0800, Zhi Yong Wu wrote:
> On Tue, Sep 25, 2012 at 5:28 PM, Dave Chinner wrote:
> > On Sun, Sep 23, 2012 at 08:56:28PM +0800, zwu.ker...@gmail.com wrote:
> >> From: Zhi Yong Wu
> >>
> >> Introduce one new mount option '-o hottrack',
> >> and add its parsing s
On Thu, Sep 27, 2012 at 02:54:22PM +0800, Zhi Yong Wu wrote:
> On Thu, Sep 27, 2012 at 12:03 PM, Dave Chinner wrote:
> > On Sun, Sep 23, 2012 at 08:56:32PM +0800, zwu.ker...@gmail.com wrote:
> >> From: Zhi Yong Wu
> >>
> >> Fork and run one kernel kthread to calculate
> >> that temperature base
On Thu, Sep 27, 2012 at 02:28:12PM +0800, Zhi Yong Wu wrote:
> On Thu, Sep 27, 2012 at 11:54 AM, Dave Chinner wrote:
> > On Sun, Sep 23, 2012 at 08:56:31PM +0800, zwu.ker...@gmail.com wrote:
> >> From: Zhi Yong Wu
> >>
> >> Miscellaneous features that implement hot data tracking
> >> and genera
35 matches
Mail list logo
