what does the function btrfs_run_delayed_refs means? At the start of
the function there is a simple explanation, who can give me a detailed
explanation ？
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo i
transaction_kthread can periodically commit data and metedata
to disk,similarly btrfs_writepages can write data page to disk, in
which situation btrfs_writepages function is called? and i cannot find
btrfs_writepages is called in btrfs code? who can tell me?
--
To unsubscribe from this list:
Hello Jan,
On 10/24/2013 11:36 PM, Jan Schmidt wrote:
On Thu, October 24, 2013 at 16:49 (+0200), Wang Shilong wrote:
Hello Jan,
btrfs_dec_ref() queued a delayed ref for owner of a tree block. The qgroup
tracking is based on delayed refs. The owner of a tree block is set when a
tree block is a
On thu, 24 Oct 2013 19:32:15 +0800, Wang Shilong wrote:
> On 10/24/2013 06:08 PM, Chris Mason wrote:
>> Quoting Stefan Behrens (2013-10-23 13:21:34)
>>> On Tue, 22 Oct 2013 18:55:59 +0200, Bob Marley wrote:
On 22/10/2013 10:37, Stefan Behrens wrote:
> I don't believe that this issue c
On Oct 24, 2013, at 5:13 PM, Karl Kiniger wrote:
> On Thu 131024, Chris Murphy wrote:
>>
>> On Oct 24, 2013, at 4:46 PM, Karl Kiniger wrote:
>> In what way would a r/o snapshot be modified because of moving its
>>> "mount point" ? No one is ever doing something inside.
>>
>> For the same reas
On Thu 131024, Chris Murphy wrote:
>
> On Oct 24, 2013, at 4:46 PM, Karl Kiniger wrote:
> In what way would a r/o snapshot be modified because of moving its
> > "mount point" ? No one is ever doing something inside.
>
> For the same reason I can't move or rename a read only directory even thoug
ow reason why root should be able to modify it. And
>> moving it does modify it.
>
> tries this all as root.
>
> drwxr-xr-x. 1 root root 734 Oct 24 16:41 @20131024 (this is a r/o snap)
>
> It looks to me similar to a read-only mounted filesystem:
>
> pc2:/u2/F19/@2
s all as root.
drwxr-xr-x. 1 root root 734 Oct 24 16:41 @20131024 (this is a r/o snap)
It looks to me similar to a read-only mounted filesystem:
pc2:/u2/F19/@20131024# touch foo
touch: cannot touch ‘foo’: Read-only file system
In what way would a r/o snapshot be modified because of moving
On Oct 24, 2013, at 3:57 PM, Karl Kiniger wrote:
>
> Yes they are read only snapshots (just received by btrfs receive) and
> "readonly" is a regular directory. I deliberately did not try to move
> those snapshots into other snapshots.
>
> I can move r/w snapshots around without problems
> (int
Hi
(pls see also my other reply in this thread)
On Thu 131024, Duncan wrote:
> Karl Kiniger posted on Thu, 24 Oct 2013 17:29:56 +0200 as excerpted:
>
> > Dear list, (newbie alert)
> >
> > After sucessfully sending and receiving a dozen of related snapshots I
> > want to move them all to the re
lder but I cannot:
> >
> > ls -l
> > .
..
> > drwxr-xr-x. 1 root root 734 Oct 24 16:36 @20131023
> > drwxr-xr-x. 1 root root 734 Oct 24 16:41 @20131024
> > drwxr-xr-x. 1 root root 734 Oct 24 16:41 F19
> > drwxr-xr-x. 1 root root 0 Oct 24 17:21 readonly
&
Hello, i suggest temporary solution to use swap file under btrfs.
I test it, and it work good.
I invent simple the way, how create and using swap file, just see
following sh code:
swapfile=$(losetup -f) #free loop device
truncate -s 8G /swap #create 8G sparse swap file
losetup $swapfile /swap #
On Tue, Sep 17, 2013 at 10:21 AM, David Sterba wrote:
> The command has been moved and we should rename the files accordingly,
> so the entry point is now in cmds-rescue.c and the core functionality
> in it's own file.
>
> Return codes of btrfs_recover_chunk_tree have been simplified not to
> requ
Karl Kiniger posted on Thu, 24 Oct 2013 17:29:56 +0200 as excerpted:
> Dear list, (newbie alert)
>
> After sucessfully sending and receiving a dozen of related snapshots I
> want to move them all to the readonly folder but I cannot:
I see you mention fedora 19 in a followup, but for those not o
Thanks for the comments.
I took care of it in the recent patch
([PATCH] btrfs-progs: make filesystem show by label work)
with this -d/-m option may accept the argument as well.
except for -m with the argument is of unmounted disk.
Found a new bug.. more than one subvol of a fsid might
have bee
; drwxr-xr-x. 1 root root 706 Oct 24 16:31 @20131021
> drwxr-xr-x. 1 root root 734 Oct 24 16:36 @20131023
> drwxr-xr-x. 1 root root 734 Oct 24 16:41 @20131024
> drwxr-xr-x. 1 root root 734 Oct 24 16:41 F19
> drwxr-xr-x. 1 root root 0 Oct 24 17:21 readonly
>
>
> mv \@
The result of the scrubbing came back today and it was not pretty:
...
scrub done for b64daec7-6c14-4996-94b3-80c6abfa26ce
scrub started at Wed Oct 23 23:01:22 2013 and finished after
34990 seconds
total bytes scrubbed: 12.55TB with 3859542 errors
error details: csum=3859542
arrgh, forgot to mention:
pc2:~> btrfs --version
Btrfs v0.20-rc1
Fedora 19 x86_64
Karl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, October 24, 2013 at 16:49 (+0200), Wang Shilong wrote:
> Hello Jan,
>
>> btrfs_dec_ref() queued a delayed ref for owner of a tree block. The qgroup
>> tracking is based on delayed refs. The owner of a tree block is set when a
>> tree block is allocated, it is never updated.
>>
>> When you
root 734 Oct 24 16:41 @20131024
drwxr-xr-x. 1 root root 734 Oct 24 16:41 F19
drwxr-xr-x. 1 root root 0 Oct 24 17:21 readonly
mv \@20131024 readonly
mv: cannot move ‘@20131024’ to ‘readonly/@20131024’: Read-only file system
I know I can create other new ro snapshots within the readonly
On Thu, Oct 24, 2013 at 04:51:00PM +0200, David Sterba wrote:
> On Wed, Oct 23, 2013 at 10:08:16AM +0800, Anand Jain wrote:
> > On 10/22/13 10:33 PM, David Sterba wrote:
> > >On Tue, Oct 22, 2013 at 01:53:22PM +0800, Anand Jain wrote:
> > >>@@ -386,7 +395,7 @@ static int btrfs_scan_kernel(void *sea
On Wed, Oct 23, 2013 at 10:08:16AM +0800, Anand Jain wrote:
> On 10/22/13 10:33 PM, David Sterba wrote:
> >On Tue, Oct 22, 2013 at 01:53:22PM +0800, Anand Jain wrote:
> >>@@ -386,7 +395,7 @@ static int btrfs_scan_kernel(void *search)
> >> static const char * const cmd_show_usage[] = {
> >>- "btr
Hello Jan,
> btrfs_dec_ref() queued a delayed ref for owner of a tree block. The qgroup
> tracking is based on delayed refs. The owner of a tree block is set when a
> tree block is allocated, it is never updated.
>
> When you allocate a tree block and then remove the subvolume that did the
> allo
with design revamp around filesystem show the fsid filter
by label wasn't planned. but apparently that seemed to be
necessary. this patch will fix it.
Signed-off-by: Anand Jain
---
cmds-filesystem.c | 120 -
1 files changed, 73 insertions(+),
On Thu, Oct 24, 2013 at 10:22:28PM +0800, lilofile wrote:
> Oct 24 21:25:36 host1 kernel: [ 3000.809563] []
> blkdev_issue_discard+0x1b4/0x1c0
There's an discard/TRIM operation being done on all of the devices,
current progs do not report that and it's really confusing. Fixed in
integration branc
when i create raid5 in btrfs ,command like this:
./mkfs.btrfs -d raid5 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
/dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm -f
WARNING! - Btrfs v0.20-rc1-358-g194aa4a-dirty IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before u
Hi Chris,
this needs to go to 3.12, the patch is only in btrfs-next. The bug can
happen with systemd journal + balance, the fix helps quite a lot of
users out there. (https://bugzilla.kernel.org/show_bug.cgi?id=63411)
I have cherry-picked the patch to current master, applies cleanly and
the test
btrfs_dec_ref() queued a delayed ref for owner of a tree block. The qgroup
tracking is based on delayed refs. The owner of a tree block is set when a
tree block is allocated, it is never updated.
When you allocate a tree block and then remove the subvolume that did the
allocation, the qgroup accou
On 10/24/2013 06:08 PM, Chris Mason wrote:
Quoting Stefan Behrens (2013-10-23 13:21:34)
On Tue, 22 Oct 2013 18:55:59 +0200, Bob Marley wrote:
On 22/10/2013 10:37, Stefan Behrens wrote:
I don't believe that this issue can ever happen. I don't believe that
somewhere on the path to the flash memo
On 07/20/2013 12:51 AM, Mark Fasheh wrote:
> On Thu, Jul 11, 2013 at 12:26:50AM +0200, David Sterba wrote:
>> On Wed, Jul 10, 2013 at 10:45:45AM -0700, Mark Fasheh wrote:
>>> Well, what do I get when I pretend I don't care any more? The little voice
>>> in my head says "keep plugging away". Here's
On thu, 24 Oct 2013 06:08:42 -0400, Chris Mason wrote:
> Quoting Stefan Behrens (2013-10-23 13:21:34)
>> On Tue, 22 Oct 2013 18:55:59 +0200, Bob Marley wrote:
>>> On 22/10/2013 10:37, Stefan Behrens wrote:
I don't believe that this issue can ever happen. I don't believe that
somewhere on
On Thu, Oct 24, 2013 at 12:44:43AM +0800, Eryu Guan wrote:
> +_cleanup()
> +{
> + cd /
Using root as temporary directory?
> + rm -f $tmp.*
> + $UMOUNT_PROG $loop_mnt
> + _destroy_loop_device $loop_dev1
> + losetup -d $loop_dev2 >/dev/null 2>&1
> + _destroy_loop_device $loo
Quoting Stefan Behrens (2013-10-23 13:21:34)
> On Tue, 22 Oct 2013 18:55:59 +0200, Bob Marley wrote:
> > On 22/10/2013 10:37, Stefan Behrens wrote:
> >> I don't believe that this issue can ever happen. I don't believe that
> >> somewhere on the path to the flash memory, to the magnetic disc or to
>
Quoting Sean Clarke (2013-10-23 15:26:15)
> Hi,
>I have an Intel Core i7 based fileserver with 18TB BTRFS in a 6x
> 3TB RAID 1+0 configuration. The system was working fine running Ubuntu
> 13.04 (kernel 3.11.0-12-generic). The system was upgraded to Ubuntu
> 13.10 (kernel 3.11) and began to loc
On Thu, 24 Oct 2013 14:54:15 +0900
Tomasz Chmielewski wrote:
> On Wed, 23 Oct 2013 13:28:44 +0900
> Tomasz Chmielewski wrote:
>
> OK, putting high load aside - it finished, with no errors:
>
> # btrfs scrub status /mnt/lxc1
> scrub status for 8d08ad6d-4543-4fe5-8b1b-640dc1423d41
> scru
35 matches
Mail list logo
