[Referring to https://lkml.org/lkml/2012/1/17/381], and perhaps I'm a bit
previous, but what are the command sequence to change the raid levels?
Wouldn't mind being pointed to git manual if better for you.
Well done and thank you to all involved.
--
To unsubscribe from this list: send the line "
Alex bpmit.com> writes:
The closing square bracket got caught up in the URL: sb
https://lkml.org/lkml/2012/1/17/381
--
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://vg
Thank you very much Ilya.
--
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
Hi All,
I've come across the 'gotcha' in XFS where the inode size defaults to 256 [1]
whereas for SELinux the attributes play better when you initialise it at
creation to 512.
>From my reading of the btrfs specs [2] it doesn't look like you'll get caught
with that as the inodes "will not contain
David Sterba jikos.cz> writes:
>
> That's right. Inode represented as btrfs_inode_item does not contain any
> xattr fields, they're stored independently as a btrfs_dir_item of type
> BTRFS_FT_XATTR . Due to the way the b-tree keys are built, the xattr
> item key should be stored near the inode i
Helmut Hullen t-online.de> writes:
>
>
> Where is the problem, how can I use the full space?
>
> Viele Gruesse!
> Helmut
Effectively it's missing the trigger to rebalance when the 'primary' device
starts to get full, or just to randomly spread the data between the devices.
Isn't this going
>
>No, a balance isn't going to help here. RAID-0 requires a minimum
> of 2 chunks in a block group. With two disks, you're only going to be
> able to fill the smallest one before you run out of space.
>
> > Isn't this going to be a problem for anyone restoring from a backup? Lots of
> > dat
Hugo Mills carfax.org.uk> writes:
>
> On Sat, Mar 17, 2012 at 01:36:04PM +0000, Alex wrote:
>
>I don't have this problem personally. I just know something about
> the way btrfs allocates chunks. I think you meant Helmut has the
> problem. :)
>
> > I&
>I'm working on a comprehensive explanation of the limits on btrfs's
> space usage, and a little JavaScript tool to help plan/explain disk
> usage.
Thank you Hugo.
Given the kernel 3.3 release yesterday [1] we've gained the ability to restripe
to different raid levels after the fact. So I gu
Hugo Mills carfax.org.uk> writes:
>Basically, the kernel needs to know which devices hold which btrfs
> filesystems (organised by UUID) before it tries to mount them. So,
> there's an ioctl that is used for sending that data to the kernel, and
> a userspace tool (btrfs dev scan) that enumera
Hi all,
Just a quick question but can't find an obvious answer.
Can I create/convert a existing (btrfs) directory into a subvolume?
It would be very helpful when transferring 'partitions' into btrfs.
I found a similar question way back in google, but that site is
down now generally.
Thanks in a
David Sterba jikos.cz> writes:
>
> On Tue, Mar 27, 2012 at 05:19:06PM +0000, Alex wrote:
> > Can I create/convert a existing (btrfs) directory into a subvolume?
>
> For the reference there's an entry at the wiki:
>
>
http://btrfs.
Phillip Susi ubuntu.com> writes:
>
> So currently btrfs's concept of raid0 is "stripe across as many disks as
> possible, with a minimum of 2 disks". Is there any reason for that
> minimum? I don't see why it can't allow only one if that's the best it
> can manage.
>
That's called "Single"
Chris Mason oracle.com> writes:
>
> Hi everyone,
>
> This pull request is pretty big, picking up patches that have been under
> development for some time. I have it in two branches:
>
Thank you all guys for your time, effort and responses here.
No problems here so far ;-)
--
To unsubscri
Hey guys,
I have done some work about triple-parity RAID and is posted in
linuxquestions.org
Please go there and search for "Is this enough for us to have
triple-parity RAID?"
As a die-hard follower of Linux, I truly wish btrfs would
have triple-parity RAID integrated in the future. For those wh
180
[503553.950870] [] ret_from_fork+0x42/0x70
[503553.950875] [] ? kthread_create_on_node+0x180/0x180
[503553.950878] ---[ end trace c494302704bb5eb1 ]---
[503553.950883] BTRFS: error (device sdb) in cleanup_transaction:1692:
errno=-5 IO failure
[503553.950887] BTRFS info (device sdb): delayed_refs has NO entry
other stuf
1 official Debian AMD64 kernel. Multi-subvol including root
with set-default enacted. 32k's adopted per Chris's post.
Install:
virt-install --connect qemu:///system -n china -r 256 --disk
path=/var/lib/libvirt/images/china.img,size=4 -c
/home/alex/debian-testing-amd64-CD-1.iso --vnc --noautocon
Roman Mamedov romanrm.ru> writes:
(Machine has no other load at all)
No material difference between cache types (none, writeback and writethrough)
when I tried.
I had been using partition based KVM which is obviously going to
be much faster.
Seems a little unfair on btrfs to just to look at abs
Hubert Kario qbs.com.pl> writes:
>
>
> From what I heard, this is caused by slow KVM CD virtualisation.
>
> Try to install it and do some tests then.
>
You read my mind :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vg
Alex bpmit.com> writes:
>
> Roman Mamedov romanrm.ru> writes:
>
> (Machine has no other load at all)
>
>
Roman Mamedov didn't write it, I did, I had huge trouble getting past the 80
char limit thing! Sorry Roman.
--
To unsubscribe from this list: send the
Note to self: if wanting to test btrfsck and give self a scare don't introduce
the RT version of the same kernel into a (working perfectly) but not
backed-up-to-the-minute btrfs install.
Thanks. That is all.
In other news, KVM on btrfs: I'm finding the guests a little slow now I have two
guests (
Hi All,
The official wiki seems to have lost references to "scrub" if not other
commands. The last changes iss filled with account creation so I can't see
easily when that happened.
Have I missed a policy change go through which is not reflected in the
(Debian/Siduction) btrfs userland program ye
Swâmi Petaramesh petaramesh.org> writes:
>
> Hi,
>
> I have 4 machines, all converted to BTRFS about 6 months ago, now all
> running Ubuntu Quantal with kernel 3.5.0-17
1. Convert to a 16k or 32k leafsize.
2. defragment (each non-trivial file) every now and again [eg. find / -size +16k
-type
David Sterba jikos.cz> writes:
>
> Hi,
>
> On Sun, Oct 07, 2012 at 12:07:43PM +, Alex wrote:
> > The official wiki seems to have lost references to "scrub" if not other
> > commands.
Sorry, I felt sure that scrub was listed on
https://btrfs.wiki.ke
Greetings!
As one 'stuck' with 4k leaves on my main machine for the moment, can I request
the btrfs-progs v0.20 defaults to more efficient decent block sizes before
release. Most distro install programs for the moment don't give access to the
options at install time and there seems to be is a sign
Michael Kjörling kjorling.se> writes:
>
> Can btrfs deal reasonably gracefully with sudden shutdowns? (I'm
> mainly thinking of power outages which lead to logical structure
> damage but not physical media damage.)
>
Really rather well! We've had a sequence of power-cuts around here and I've
s
Hi All,
It seems my btrfs file space cache is corrupt; I had to run clear the log
through a kernel problem.
I've seen messages that the cache is rebuilt automatically, but this doesn't
seem to be true as the messages that the free space is what is expected keep
coming.
I'm running kernel 3.8.2 (
Hello
(Using btrfs userland 3.12)
I have my fs set up (below) I borrowed the Ubuntu scheme.
/@/
/@/etc
/@/var
..
get-default is 5 i.e.
AFAICT, perhaps I'm missing the obvious, getting the list of subvolumes only
(no snapshots) is no longer trivial?
# btrfs sub list /@
ERROR: can't access
Chris Murphy colorremedies.com> writes:
> Specify the mount point for the Btrfs file system and it will list all
subvols on that file system.
>
> Chris Murphy--
Thank you Chris.
When I do that on my version of the 3.12 userland:
# btrfs sub list / -o
returns nothing (with no error), which I w
Chris Murphy colorremedies.com> writes:
> > Hmm, actually you might have found a bug.
> >
> > Small typo while we're at it, below should have one l.
>
> kernel-3.13.0-0.rc6.git0.1.fc21.x86_64
> btrfs-progs-3.12-1.fc20.x86_64
>
> Chris Murphy
>
Thank you muchly!
I'm kinda glad because I didn'
Sorry KC:
All my VM's are on syslinux (actually extlinux) and btrfs:
Device Boot Start End Blocks Id System
/dev/vda1 *2048 7938047 3968000 83 Linux
/dev/vda2 7938048 8388607 225280 82 Linux swap / Solaris
root@ ~ # ll /boot
total 1
Blaz Balon laly.si> writes:
>
> I also had some problems with syslinux.
>
> For me it only works if I put boot folder to root of btrfs.
> Didn't have a chance to do more test, but I copied /boot from default
> subvolume to subvolume 0 and it boots OK.
Not sure I understand your /boot comment.
Duncan <1i5t5.duncan cox.net> writes:
>
> Alex posted on Tue, 04 Feb 2014 17:19:09 + as excerpted:
>
> > I have quite an (overly) complicated setup.
>
> I had to chuckle at that one. Fits my setup to a "T", altho they're
> different compli
Hi all,
Debian testing/Jessie-to-be; except kernels/btrfs-tools are from unstable so
usually couple of weeks later than you/Linus publish.
Linux XX 3.13-1-amd64 #1 SMP Debian 3.13.7-1 (2014-03-25) x86_64
Btrfs-tools v3.12 Debian standard (not particularly messed with looks like)
I've never had s
t bad timing my end
it seems .. tl;d(on't)r!
Qu: is anyone actively using seed devices? I saw one post relatively
recently. I can see "Ebonacco" and possibly "Killermist" are.
Kind regards
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux
On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote:
> This patchset adds btrfs encryption support.
>
> The main objective of this series is to have bugs fixed and stability.
> I have verified with fstests to confirm that there is no regression.
>
> A design write-up is coming next, however her
On Thu, 15 Sep 2016 19:33:48 +0800, Anand Jain wrote:
> Thanks for commenting. pls see inline below.
>
> On 09/15/2016 12:53 PM, Alex Elsayed wrote:
>> On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote:
>>
>>> This patchset adds btrfs encryption support.
>
On Fri, 16 Sep 2016 11:12:13 +1000, Dave Chinner wrote:
> On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote:
>>
>> This patchset adds btrfs encryption support.
>>
>> The main objective of this series is to have bugs fixed and stability.
>> I have verified with fstests to confirm that th
On Sat, 17 Sep 2016 00:38:30 -0400, Zygo Blaxell wrote:
> On Fri, Sep 16, 2016 at 06:49:53AM +0000, Alex Elsayed wrote:
>> The main issue I see is that subvolumes as btrfs has them _do_
>> introduce novel concerns - in particular, how should snapshots interact
>> with keying
On Fri, 16 Sep 2016 23:58:31 -0700, Eric Biggers wrote:
> On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote:
>>
>> This patchset adds btrfs encryption support.
>>
>>
> Hi Anand,
> Note: even better would be an authenticated encryption mode. That isn't
> yet done by ext4 or f2fs --- I
On Mon, 19 Sep 2016 14:57:33 -0400, Zygo Blaxell wrote:
> On Sat, Sep 17, 2016 at 07:13:45AM +0000, Alex Elsayed wrote:
>> IMO, this is already a flawed framing - in particular, if encrypting at
>> the extent level, one _should not_ be encrypting (or authenticating)
>>
On Mon, 19 Sep 2016 14:08:06 -0400, Zygo Blaxell wrote:
> On Sat, Sep 17, 2016 at 06:37:16AM +0000, Alex Elsayed wrote:
>> > Encryption in ext4 is a per-directory-tree affair. One starts by
>> > setting an encryption policy (using an ioctl() call) for a given
>> >
On Mon, 19 Sep 2016 11:15:18 -0400, Theodore Ts'o wrote:
> (I'm not on linux-btrfs@, so please keep me on the cc list. Or perhpas
> better yet, maybe we can move discussion to the linux-fsdevel@
> list.)
I apologize if this doesn't keep you in the CC, as I'm posting via gmane.
> Hi Anand,
>
>
On Mon, 19 Sep 2016 20:32:34 -0400, Chris Mason wrote:
> On 09/19/2016 04:58 PM, Alex Elsayed wrote:
>> When someone says "pretty simple" regarding cryptography, it's often
>> neither pretty nor simple :P
>>
>> The issue, here, is that inodes are f
Taking a stab at a different way of replying, to try and keep Ted in the loop.
On Monday, 19 September 2016 22:50:41 PDT Theodore Ts'o wrote:
> On Mon, Sep 19, 2016 at 08:32:34PM -0400, Chris Mason wrote:
> > > > That key is used to protect the contents of the data file, and to
> > > > encrypt fil
On Tue, 20 Sep 2016 07:51:52 -0800, Kent Overstreet wrote:
> On Tue, Sep 20, 2016 at 10:23:20AM -0400, Theodore Ts'o wrote:
>> On Tue, Sep 20, 2016 at 03:15:19AM -0800, Kent Overstreet wrote:
>> > Not on the list or I would've replied directly, but on Haswell,
>> > ChaCha20 (in software) is over 2
David, Holger,
Thank you for picking up that old patch of mine.
Alex.
On Fri, Jul 29, 2016 at 8:53 PM, Liu Bo wrote:
> On Fri, Jul 29, 2016 at 07:01:50PM +0200, David Sterba wrote:
>> On Thu, Jul 28, 2016 at 11:49:14AM -0700, Liu Bo wrote:
>> > > For reviewers - thi
write_unlock(&em_tree->lock);
If the "em" was in pending_chunks, it will be deleted from that list
by "remove_extent_mapping". But it looks like in this case we also
need to drop the extra ref on "em", which was held by pending_chunks
list. I don't see it being
t_empty(&fs_info->pinned_chunks)) {
struct extent_map *em;
em = list_first_entry(&fs_info->pinned_chunks,
struct extent_map, list);
list_del_init(&em->list);
free_extent_map(em);
}
Can you please comment on that?
Thanks,
Alex.
O
don't really add any value". But with the extra ref-count, the
extent buffer will not be properly freed and will cause a memory leak,
won't it?
Thanks,
Alex.
On Tue, Nov 6, 2018 at 4:30 PM David Sterba wrote:
>
> On Wed, Aug 15, 2018 at 06:26:50PM +0300, Nikolay Borisov wro
Hi Nikolay,
In my kernel (4.14.x) the flag is called EXTENT_BUFFER_DUMMY, and
indeed I see that there is an extra dec-ref for them in
free_extent_buffer().
Thanks for clearing that up,
Alex.
On Wed, Feb 6, 2019 at 4:36 PM Nikolay Borisov wrote:
>
>
>
> On 6.02.19 г. 16:26 ч.,
er deleted objects, if yes, then how? Thanks in advance!
--
Alex Shashkov
ize
things, but if we do that we might as well be using a filesystem like XFS. Are
there fixes queued up that will solve the problems listed in the Bugzilla
ticket referenced above? Or is our I/O-intensive workload just not a good fit
for Btrfs?
Thanks,
Alex--
To unsubscribe from this list: send
way, I hope this all makes sense, and sorry for it being so long,
but thought it best to give as much detail as possible. Thank you for
your help.
Alex
Output:
uname -a:
Linux TheMatrix 4.13.0-32-generic #35-Ubuntu SMP Thu Jan 25 09:13:46
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
btrfs --version:
bt
ning a
"btrfs check --repair" or rebuilding filesystems (both of which require a
significant amount of downtime)?
Thanks,
Alex--
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 Feb 15, 2018, at 2:42 PM, Nikolay Borisov wrote:
>
> On 15.02.2018 21:41, Alex Adriaanse wrote:
>>
>>> On Feb 15, 2018, at 12:00 PM, Nikolay Borisov wrote:
>>>
>>> So in all of the cases you are hitting some form of premature enospc.
>>&
d mode.
"btrfs filesystem df" output, after rebooting:
Data, single: total=668.01GiB, used=548.25GiB
System, single: total=32.00MiB, used=112.00KiB
Metadata, single: total=15.00GiB, used=9.11GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
We don't run btrfs scrubs. I'm
On Mar 2, 2018, at 11:29 AM, Liu Bo wrote:
> On Thu, Mar 01, 2018 at 09:40:41PM +0200, Nikolay Borisov wrote:
>> On 1.03.2018 21:04, Alex Adriaanse wrote:
>>> Thanks so much for the suggestions so far, everyone. I wanted to report
>>> back on this. Last Friday I mad
g that comes to mind is to try and tune the default commit
> interval. Currently this is 30 seconds, meaning a transaction will
> happen roughly every 30 seconds (unless there is enough data batched
> that it should happen "NOW", where "NOW" is defined as "during the life
one should not be tagged as "stable"? At
least the missing bio_put in free_fs_devices is not an error case,
and would happen every time.
Thanks,
Alex.
an max_extent_size will
immediately fail. But if we unmount and mount again, we will have
plenty of space.
This happens to me on 4.14, but I think the mainline still has the same logic.
Thanks,
Alex.
Hi All,
Taking a step back as well- there is also the possibility that you
might not need snapshots
I say this as you're a noobie- like me!
If you're a noobie, I assume you're not using it to host some massive
Oracle DB and need all these features
If you're using this for a home media server or s
Hi,
It would be good but perhaps each task should be created via cronjobs
instead of having a script running all the time or one script via one
cronjob
Working in the enterprise environment for a major bank, we quickly
learn that these sort of daily tasks should be split up
Kind Regards,
Alex
teevie 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.8-1~bpo8+1 (2016-10-19)
x86_64 GNU/Linux
% btrfs --version # Installed from Debian's jessie-backports
btrfs-progs v4.7.3
% sudo btrfs fi show
[sudo] password for alex:
Label: '[root]' uuid: 06c6565d-af6c-4
Qu Wenruo cn.fujitsu.com> writes:
> > - As of now uses "user" keytype, I am still considering/
> >evaluating other key type such as logon.
>
> UI things can always be reconsidered later.
> Never a big problem.
This is not only a UI concern, but an API/ABI concern.
To use eCryptFS as an exa
Signed-off-by: Alex Lyakas
---
fs/btrfs/disk-io.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 4545e2e..4420ab2 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -296,52 +296,52 @@ static int
e_bio
will,
but it is better than to have a silent metadata corruption on disk.
Signed-off-by: Alex Lyakas
---
fs/btrfs/disk-io.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 4420ab2..cf85714 100644
--- a/fs/
/file/d/0B9rmyUifdvMLbHBuSWU5dlVKNWc. Due to
this I did not include the chunk tree UUID check. Hoping very much
that fs UUID should always be valid for all tree blocks))
Thanks,
Alex.
On Mon, Feb 22, 2016 at 12:28 PM, Filipe Manana wrote:
> On Mon, Feb 22, 2016 at 9:46 AM, Alex Lyakas wr
Nicholas,
On Sat, Mar 12, 2016 at 12:19 AM, Nicholas D Steeves wrote:
> On 10 March 2016 at 06:10, Alex Lyakas wrote:
>> csum_dirty_buffer was issuing a warning in case the extent buffer
>> did not look alright, but was still returning success.
>> Let's return error
ormal COW.
Is my understanding correct?
I have also few nitpicks on the code, will reply to relevant patches.
Thanks for doing this work,
Alex.
On Tue, Mar 22, 2016 at 3:35 AM, Qu Wenruo wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/linux.git wang_dedu
Hi Qu, Wang,
On Tue, Mar 22, 2016 at 3:35 AM, Qu Wenruo wrote:
> Since we will introduce a new on-disk based dedupe method, introduce new
> interfaces to resume previous dedupe setup.
>
> And since we introduce a new tree for status, also add disable handler
> for it.
>
> Signed-off-by: Wang Xiao
Thanks for your comments, Qu.
Alex.
On Wed, Mar 30, 2016 at 2:34 AM, Qu Wenruo wrote:
>
>
> Alex Lyakas wrote on 2016/03/29 19:22 +0200:
>>
>> Greetings Qu Wenruo,
>>
>> I have reviewed the dedup patchset found in the github account you
>> mentioned. I h
Hello Qu, Wang,
On Wed, Mar 30, 2016 at 2:34 AM, Qu Wenruo wrote:
>
>
> Alex Lyakas wrote on 2016/03/29 19:22 +0200:
>>
>> Greetings Qu Wenruo,
>>
>> I have reviewed the dedup patchset found in the github account you
>> mentioned. I have several questions
locks, generating more delayed refs.
At which point this recursion stops?
Do we assume that at some point all needed free-space tree blocks have
been COW'ed already, and we do not COW a tree block more than once per
transaction (unless it was written to disk due to memory pressure)?
Thanks!
d on one of the latest
kernels, because
here btrfs is part of the larger system, and upgrading the kernel is a
significant effort.
Hence marking the patch as RFC.
Hopefully, this patch still has some value to the community.
Signed-off-by: Alex Lyakas
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.
was introduced in kernel 3.0 above.
> Arent the btrfs headers should be there ? do they exist in another
> package ? maybe fs-headers or something like that ?
Try using the below simple Makefile[1] to compile btrfs loadable
module. You need to have the kernel-headers package installed.
You
Hi Liu,
On Wed, Mar 22, 2017 at 1:40 AM, Liu Bo wrote:
> On Sun, Mar 19, 2017 at 07:18:59PM +0200, Alex Lyakas wrote:
>> We have a commit_root_sem, which is a read-write semaphore that protects the
>> commit roots.
>> But it is also used to protect the list of caching blo
urrently, the user space has no idea when the deletion will
start, or when it is completed (it has to track the ROOT_ITEM, drop
progress, ORPHAN_ITEM etc.). That's why I was thinking, that at least
committing a transaction on snap_destroy could ensure that deletion
will not be reverted.
Thanks,
Alex.
--
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
;node) <
> + BTRFS_MIXED_BACKREF_REV)
> + ret = btrfs_drop_snapshot(root, NULL, 0, 0);
> + else
> + ret = btrfs_drop_snapshot(root, NULL, 1, 0);
> + /*
> +* If we encounter a transaction abort during snapshot cleani
bserve such behavior? Do you believe it's problematic?
Thanks,
Alex.
On Mon, Feb 25, 2013 at 12:20 PM, Miao Xie wrote:
> On sun, 24 Feb 2013 21:49:55 +0200, Alex Lyakas wrote:
>> Hi Miao,
>> can you please explain your solution a bit more.
>>
>> On
Hi Miao,
On Mon, Mar 25, 2013 at 3:51 AM, Miao Xie wrote:
> On Sun, 24 Mar 2013 13:13:22 +0200, Alex Lyakas wrote:
>> Hi Miao,
>> I am seeing another issue. Your fix prevents from TRANS_START to get
>> in the way of a committing transaction. But it does not prevent from
s at some point?
>
> Yes. The progress or performance impact depends on amount of data shared
> among the snapshots and used / free space fragmentation.
>
> david
> --
> 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
Thanks,
Alex.
--
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
Hi Jan,
I have manually applied this patch and also your previous patch onto
kernel 3.8.2, but, unfortunately, I am still hitting the issue:(
I will check further whether I can be more helpful in debugging this
issue, than just reporting it:(
Thank for your help,
Alex.
On Wed, Mar 20, 2013 at
Hi David,
maybe my old patch
http://www.spinics.net/lists/linux-btrfs/msg19739.html
can help this issue?
Thanks,
Alex.
On Wed, Apr 3, 2013 at 8:23 PM, David Sterba wrote:
> On Wed, Apr 03, 2013 at 04:33:22AM +0200, Harald Glatt wrote:
>> However what I actually did was:
>> #
its that take like 80
seconds, out of which like 50 seconds are spent in the do-while loop
of btrfs_commit_transaction.
Thanks,
Alex.
On Mon, Mar 25, 2013 at 11:11 AM, Alex Lyakas
wrote:
> Hi Miao,
>
> On Mon, Mar 25, 2013 at 3:51 AM, Miao Xie wrote:
>> On Sun, 24 Mar 2013 13:13
Hugo Mills wrote:
> On Thu, Apr 18, 2013 at 02:45:24PM +0100, Martin wrote:
>> Dear Devs,
>> Note that esata shows just the disks as individual physical disks, 4 per
>> disk pack. Can physical disks be grouped together to force the RAID data
>> to be mirrored across all the nominated groups?
>
>
Martin wrote:
> Or perhaps include the same Ceph code routines into btrfs?...
That's actually what I was thinking. The CRUSH code is actually already
pretty well factored out - it lives in net/ceph/crush/ in the kernel source
tree, and is treated as part of 'libceph' (which is used by both th
Roger Binns wrote:
> On 27/04/13 14:40, Calvin Walton wrote:
>> Unfortunately, bugfixes in btrfs have tended to be *not* backported;
>> aside from a few special cases, ...
>
> Your efforts to scare me are admirable, but have failed :-)
>
> As btrfs development has progressed, the probability of
it still needed
after your fix to check the stransid field ? (it doesn't hurt to check
it)
Clearring/Not clearing the rtransid - does it bring any value?
rtransid is the local transid of when we had completed the "receive"
process for this snap. Is there any interesting usage of this
: [ 7130.418455] []
system_call_fastpath+0x1a/0x1f
Kernel is 3.8.2.
Some investigation suggests that there are no pending IOs on the block
device level.
Can anybody advise what could have caused such a hang?
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
I'm not entirely sure what went completely wrong. Three possibilities are most
likely, and they're listed below.
For reference, here are supplemental materials split out into their own
pastebins:
* btrfs-debug-tree -R log http://pastebin.com/7ePy9sin
* dmesg log http://pastebin.com/s1sdJRyd
(btr
Oh, I see... Well at least now I know. Thanks!
I'll probably go for the "safer" route of using 3.10... Though I'd like to know
how stable the current RC is wrt btrfs, if instead I should wait for the
release.
~Alex
On May 30, 2013, at 8:52 AM, Josef Bacik wrote:
> On
ytes));
So that when transaction aborts, FS is marked as "bad", and then all
these waits will complete, so that the user can unmount?
Or some other way to fix this problem?
Thanks,
Alex.
P.S: should I open a bugzilla for this?
--
To unsubscribe from this list: send the line "
Hi Miao,
On Thu, May 9, 2013 at 10:57 AM, Miao Xie wrote:
> Hi, Alex
>
> Could you try the following patchset?
>
> git://github.com/miaoxie/linux-btrfs.git trans-commit-improve
>
> I think it can avoid the problem you said below.
>
> Note: this patchset is against c
Hi Miao,
On Thu, Jun 13, 2013 at 6:08 AM, Miao Xie wrote:
> On wed, 12 Jun 2013 23:11:02 +0300, Alex Lyakas wrote:
>> I reviewed the code starting from:
>> 69aef69a1bc154 Btrfs: don't wait for all the writers circularly during
>> the transaction commit
>> until
to the transaction, which is
the committer itself (your fixes doesn't hurt though). Is that
correct?
Thanks for helping,
Alex.
--
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
handle kernel paging request at
8800487abd68
Thanks anyways for fixing this.
Alex.
On Wed, Dec 19, 2012 at 10:10 AM, Miao Xie wrote:
> Locking and unlocking delayed ref mutex are in the different functions,
> and the name of lock functions is not uniform, so the readability is not
&g
Thanks for commenting Josef. I hope your head will get better:)
Actually, while re-looking at the code, I see that there are couple of
"goto cleanup;", before we ensure that all the writers have detached
from the committing transaction. So Liu's code is still needed, looks
like.
Th
then is stuck on chunk_mutex.
Was this patch:
Btrfs: don't re-enter when allocating a chunk
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c6b305a89b1903d63652691ad5eb9f05aa0326b8
introduced to fix this deadlock?
Thanks,
Alex.
[1]
[] do_chunk_alloc+0x8d/0x510 [
Hi Miao,
On Mon, Jun 17, 2013 at 4:51 AM, Miao Xie wrote:
> On sun, 16 Jun 2013 13:38:42 +0300, Alex Lyakas wrote:
>> Hi Miao,
>>
>> On Thu, Jun 13, 2013 at 6:08 AM, Miao Xie wrote:
>>> On wed, 12 Jun 2013 23:11:02 +0300, Alex Lyakas wrote:
>>
1 - 100 of 377 matches
Mail list logo
