Hi,
Am 22.03.2013 07:41, schrieb cwillu:> On Fri, Mar 22, 2013 at 12:39 AM,
Stefan Priebe - Profihost AG
> wrote:
>> Already tried with value 5 did not help ;-( and it also happens with
>> plain cp copying a 15gb file and aborts at about 80%
>
> You tried -musage=5? Your original email said -dus
All,
When adding a subvolume to a qgroup, pre-existing files in that
subvolume are not counted in the referenced/exclusive space of the
qgroup. Is this intended behavior ?
I create a subvol with one file:
# mkfs.btrfs /dev/sdg
# mount /dev/sdg /mnt/fulldisk
# cd /mnt/fulldisk
# btrfs
On Wed, Mar 20, 2013 at 09:08:49PM +0100, Martin Steigerwald wrote:
> The fragmentation visuation tool works nicely. Tried it on about 200 GiB
> /home, almost no fragmentation, some 3-4%, but mostly 0.something%,
> and on about 20 GiB root, were some chunks were fragmented upto 30-40%.
>
> What ki
Hello,
> All,
>
> When adding a subvolume to a qgroup, pre-existing files in that subvolume are
> not counted in the referenced/exclusive space of the qgroup. Is this intended
> behavior ?
Btrfs quota rescan has not been implemented yet. So until now, the pre-existing
files are not counted.
From: Wang Shilong
Since btrfs quota rescan has not been implemented yet,
a user complains that "btrfs qgroup show" lists qgroup
referenced/exclusive be negative. However, this should
not happen even if overflow happens,because the type for
qgroup referenced/exclusive is u64,fix it.
Signed-off-b
Hello Arne,
Since "quota rescan" has not been implemented yet,
overflow can happen, so until now, we can have a check when
doing accounting in the kernel, if the referenced/exclusive is not
enough to delete, we just make it to be 0 and give a warning.
Otherwise, user may get a strange integer(be
On Thu, Mar 21, 2013 at 01:58:19PM -0400, Chris Mason wrote:
> I really like this patch, but we're going to have to sit on it until the
> next merge window. It's fairly large and we need to stick with things
> that are more clearly bug fixes for now.
>
> But, I don't have a problem with queuing i
Quoting Alexandre Oliva (2013-03-22 01:27:42)
> On Mar 21, 2013, Chris Mason wrote:
>
> > Quoting Chris Mason (2013-03-21 14:06:14)
> >> With mmap the kernel can pick any given time to start writing out dirty
> >> pages. The idea is that if the application makes more changes the page
> >> become
Hi Chris,
> Which kernel are you running?
>
> -chris
vanilla 3.8.3.
>>>
>>> Ok, with the 3.9 merge window Josef changed how we do the reservations.
>>> Are you able to try a slightly more experimental kernel?
any ideas what i can check? 3.9-rc3 gives me same results.
Greets
On 22.03.2013 13:03, Wang Shilong wrote:
> Hello Arne,
>
> Since "quota rescan" has not been implemented yet,
>
> overflow can happen, so until now, we can have a check when
> doing accounting in the kernel, if the referenced/exclusive is not
> enough to delete, we just make it to be 0 and give a
On Fri, March 22, 2013 at 12:53 (+0100), Wang Shilong wrote:
> From: Wang Shilong
>
> Since btrfs quota rescan has not been implemented yet,
> a user complains that "btrfs qgroup show" lists qgroup
> referenced/exclusive be negative. However, this should
> not happen even if overflow happens,bec
Hello,
>
> On Fri, March 22, 2013 at 12:53 (+0100), Wang Shilong wrote:
>> From: Wang Shilong
>>
>> Since btrfs quota rescan has not been implemented yet,
>> a user complains that "btrfs qgroup show" lists qgroup
>> referenced/exclusive be negative. However, this should
>> not happen even if ov
Hello,
> Hello,
>
>>
>> On Fri, March 22, 2013 at 12:53 (+0100), Wang Shilong wrote:
>>> From: Wang Shilong
>>>
>>> Since btrfs quota rescan has not been implemented yet,
>>> a user complains that "btrfs qgroup show" lists qgroup
>>> referenced/exclusive be negative. However, this should
>>>
On Fri, Mar 22, 2013 at 06:11:56AM -0600, Stefan Priebe - Profihost AG wrote:
> Hi Chris,
>
> > Which kernel are you running?
> >
> > -chris
>
> vanilla 3.8.3.
> >>>
> >>> Ok, with the 3.9 merge window Josef changed how we do the reservations.
> >>> Are you able to try a slig
Hi Josef,
Am 22.03.2013 14:53, schrieb Josef Bacik:
> On Fri, Mar 22, 2013 at 06:11:56AM -0600, Stefan Priebe - Profihost AG wrote:
>> Hi Chris,
>>
>>> Which kernel are you running?
>>>
>>> -chris
>>
>> vanilla 3.8.3.
>
> Ok, with the 3.9 merge window Josef changed how w
On Thu, Mar 21, 2013 at 11:25 AM, Eric Sandeen wrote:
> On 3/21/13 10:29 AM, Jon Nelson wrote:
>> On Thu, Mar 21, 2013 at 10:11 AM, Eric Sandeen wrote:
>>> On 3/21/13 10:04 AM, Jon Nelson wrote:
>> ...
2. the current git btrfs-show and btrfs fi show both output
*different* devices for d
On Mar 22, 2013, Chris Mason wrote:
> Are you using compression in btrfs or just in leveldb?
btrfs lzo compression.
> I'd like to take snapshots out of the picture for a minute.
That's understandable, I guess, but I don't know that anyone has ever
got the problem without snapshots. I mean, ev
I'm running openSUSE 12.3 on x86_64.
I was running a balance:
btrfs balance -dusage=5 -v /
using the latest btrfs tools code from git (as of this writing)
and got a crash:
[304158.496250] btrfs: found 75 extents
[304159.309289] btrfs: relocating block group 2303295684608 flags 17
[304159.839886]
Quoting Alexandre Oliva (2013-03-22 10:17:30)
> On Mar 22, 2013, Chris Mason wrote:
>
> > Are you using compression in btrfs or just in leveldb?
>
> btrfs lzo compression.
Perfect, I'll focus on that part of things.
>
> > I'd like to take snapshots out of the picture for a minute.
>
> That's
We've had a few users who wouldn't (or couldn't) provide us btrfs-images because
we maintain the file names when making an image. So introduce a sanitize
option. There are two uses, one that is fast and the other that is dog slow.
The fast way just generates garbage that's equal in length to the
On Fri, Mar 22, 2013 at 07:56:41AM -0600, Stefan Priebe - Profihost AG wrote:
> Hi Josef,
> Am 22.03.2013 14:53, schrieb Josef Bacik:
> > On Fri, Mar 22, 2013 at 06:11:56AM -0600, Stefan Priebe - Profihost AG
> > wrote:
> >> Hi Chris,
> >>
> >>> Which kernel are you running?
> >>>
> >>
Incomplete writes for leveldb should just result in lost updates, not
corruption. Also, we do stop writes before the snapshot is initiated
so there should be no in-progress writes to leveldb other than leveldb
compaction (though that might be something to investigate).
-Sam
On Fri, Mar 22, 2013 a
On Fri, Mar 22, 2013 at 10:26:59AM -0400, Chris Mason wrote:
> Quoting Alexandre Oliva (2013-03-22 10:17:30)
> > On Mar 22, 2013, Chris Mason wrote:
> >
> > > Are you using compression in btrfs or just in leveldb?
> >
> > btrfs lzo compression.
>
> Perfect, I'll focus on that part of things.
>
In this case, I think Alexandre is scanning for zeros in the file. The
incomplete writes will definitely show that.
-chris
Quoting Samuel Just (2013-03-22 13:06:41)
> Incomplete writes for leveldb should just result in lost updates, not
> corruption. Also, we do stop writes before the snapshot
On Fri, 22 Mar 2013, Chris Mason wrote:
> Quoting Alexandre Oliva (2013-03-22 10:17:30)
> > On Mar 22, 2013, Chris Mason wrote:
> >
> > > Are you using compression in btrfs or just in leveldb?
> >
> > btrfs lzo compression.
>
> Perfect, I'll focus on that part of things.
>
> >
> > > I'd like
On Thu, Mar 21, 2013 at 1:56 PM, Ask Bjørn Hansen wrote:
> Hello,
>
> A few weeks ago I replaced a ZFS backup system with one backed by btrfs. A
> script loops over a bunch of hosts rsyncing them to each their own subvolume.
> After each rsync I snapshot the "host-specific" subvolume.
>
> The "
[ mmap corruptions with leveldb and btrfs compression ]
I ran this a number of times with compression off and wasn't able to
trigger problems. With compress=lzo, I see errors on every run.
Compile: gcc -Wall -o mmap-trunc mmap-trunc.c
Run: ./mmap-trunc file_name
The basic idea is to create a 25
On Thu, 21 Mar 2013 11:56:37 -0700
Ask Bjørn Hansen wrote:
> Hello,
>
> A few weeks ago I replaced a ZFS backup system with one backed by btrfs. A
> script loops over a bunch of hosts rsyncing them to each their own subvolume.
> After each rsync I snapshot the "host-specific" subvolume.
>
>
The subvolume ioctls block on the parent directory mutex that can be
held by other concurrent snapshot activity for a long time. Give the
user at least some chance to get out of this situation by allowing
to send a kill signal.
Signed-off-by: David Sterba
---
fs/btrfs/ioctl.c | 8 ++--
1 fil
Hi Josef,
Am 22.03.2013 16:54, schrieb Josef Bacik:
On Fri, Mar 22, 2013 at 07:56:41AM -0600, Stefan Priebe - Profihost AG wrote:
Hi Josef,
Am 22.03.2013 14:53, schrieb Josef Bacik:
On Fri, Mar 22, 2013 at 06:11:56AM -0600, Stefan Priebe - Profihost AG wrote:
Hi Chris,
Which kernel are you r
Quoting Chris Mason (2013-03-22 14:07:05)
> [ mmap corruptions with leveldb and btrfs compression ]
>
> I ran this a number of times with compression off and wasn't able to
> trigger problems. With compress=lzo, I see errors on every run.
>
> Compile: gcc -Wall -o mmap-trunc mmap-trunc.c
> Run:
On Fri, Mar 22, 2013 at 01:10:05PM -0600, Stefan Priebe wrote:
> Hi Josef,
> Am 22.03.2013 16:54, schrieb Josef Bacik:
> > On Fri, Mar 22, 2013 at 07:56:41AM -0600, Stefan Priebe - Profihost AG
> > wrote:
> >> Hi Josef,
> >> Am 22.03.2013 14:53, schrieb Josef Bacik:
> >>> On Fri, Mar 22, 2013 at 0
Hi Jsoef,
thanks!
Am 22.03.2013 21:49, schrieb Josef Bacik:
On Fri, Mar 22, 2013 at 01:10:05PM -0600, Stefan Priebe wrote:
Hi Josef,
Am 22.03.2013 16:54, schrieb Josef Bacik:
On Fri, Mar 22, 2013 at 07:56:41AM -0600, Stefan Priebe - Profihost AG wrote:
Hi Josef,
Am 22.03.2013 14:53, schrieb
On 3/22/13 8:59 AM, Jon Nelson wrote:
> On Thu, Mar 21, 2013 at 11:25 AM, Eric Sandeen wrote:
>> On 3/21/13 10:29 AM, Jon Nelson wrote:
>>> On Thu, Mar 21, 2013 at 10:11 AM, Eric Sandeen wrote:
On 3/21/13 10:04 AM, Jon Nelson wrote:
>>> ...
> 2. the current git btrfs-show and btrfs fi sh
34 matches
Mail list logo
