And a rough implementation design is here below. (As of now this does
not include the GNOME integration since I have no idea how to do that).
Further, implementation will contain 2 new files
/etc/init.d/btrfs and //btrfs-auto-snapshot,
any idea where does a file like btrfs-auto-snapshot should
Since the d_off in the first dirent for "." (that originates from
the 4th argument "offset" of filldir() for the 2nd dirent for "..")
is wrongly assigned in btrfs_real_readdir(), telldir returns same
offset for different locations.
| # mkfs.btrfs /dev/sdb1
| # mount /dev/sdb1 fs0
| # cd fs0
|
> And a rough implementation design is here below. (As of now this does
> not include the GNOME integration since I have no idea how to do that).
>
> Further, implementation will contain 2 new files
> /etc/init.d/btrfs and //btrfs-auto-snapshot,
>
> any idea where does a file like btrfs-auto-snapsh
Hello Anand and all,
On 2011-08-17 T 10:15 +0800 Anand Jain wrote:
> Appears that no one is working on the auto-snapshot feature for
> btrfs, so here I am implementing the same.
thanks for bringing this up! The group of features you are listing is
indeed of high interest for people using btrf
I've already done something similar. I take hourly, daily, weekly, and monthly
snapshots of my /home subvolume. Here's the script I've created for this:
#! /bin/bash
if [ "$#" -ne 2 ]; then
echo Usage $0 SNAPSHOT_PREFIX NUM_SNAPSHOTS
exit 1
fi
SNAPS=/var/lib/btrfs-root/__snapshot/home
b
On 08/09/2011 05:29 PM, Andrew Guertin wrote:
> On 06/21/2011 01:15 PM, Jan Stilow wrote:
>> Hello,
>>
>> Nirbheek Chauhan gentoo.org> writes:
>>> [...]
>>>
>>> Every few minutes, (I guess) when applications do fsync (firefox,
>>> xchat, vim, etc), all applications that use fsync() hang for severa
Andrew Guertin on 08/17/2011 09:24 AM wrote:
I (and presumably others) haven't
been able to upgrade my kernel past 2.6.38 because of this.
I'm running kernel 3.0 (Fedora 15's 2.6.40) on two boxes and I have not
seen slow downs or hangs. I use Firefox.
--
To unsubscribe from this list: send th
On 08/17/2011 10:29 AM, Michael Cronenworth wrote:
> Andrew Guertin on 08/17/2011 09:24 AM wrote:
>> I (and presumably others) haven't
>> been able to upgrade my kernel past 2.6.38 because of this.
>
> I'm running kernel 3.0 (Fedora 15's 2.6.40) on two boxes and I have not
> seen slow downs or han
On Wed, Aug 17, 2011 at 10:38:42AM -0400, Andrew Guertin wrote:
> Well I'd expect it to be somewhat uncommon, or it wouldn't survive 3
> kernel versions :) But at least 3 people have reported it, and for me at
> least it's reliably reproducible enough to bisect, so I'm quite certain
> there's somet
and much easier than trying to get snapper to compile on fedora
libblocxx ?
:-)
Ken
On 8/17/2011 9:04 AM, Dave wrote:
I've already done something similar. I take hourly, daily, weekly, and monthly
snapshots of my /home subvolume. Here's the script I've created for this:
#! /bin/bash
if [ "$
On Wed, 17 Aug 2011 10:04:33 -0400
Dave wrote:
> I've already done something similar. I take hourly, daily, weekly, and
> monthly
> snapshots of my /home subvolume. Here's the script I've created for this:
On one machine I make hourly snapshots of my /home and of the root FS as well.
The tri
On Wed, Aug 03, 2011 at 04:53:26PM -0400, Chris Mason wrote:
> I do expect a release in the next two weeks that can recover your data (and
> many others).
I actually set an appointment reminder in my Blackberry for the two week
anniversary of this email. I expect today will be a milestone in the
On Wed, Aug 17, 2011 at 11:13 AM, Roman Mamedov wrote:
> So until someone cares about snapshot ctime enough to fix this, btrfs will
> not be a convenient FS to work with timed snapshotting/cleanup.
Isn't the ctime the creation date of the original folder?
--
To unsubscribe from this list: send t
On 2011-08-17 T 09:50 -0500 Ken A wrote:
> and much easier
but less powerful:-)
> than trying to get snapper to compile on fedora libblocxx
> ? :-)
Ah, sure. Sorry. Packages for "blocxx" for:
Fedora_14 Fedora_15
RHEL-5 RHEL-6
SLE_11_SP1
iput() shouldn't be called for inodes in I_NEW state,
lets call __destroy_inode() and btrfs_destroy_inode() instead
[1.871723] WARNING: at fs/inode.c:1309 iput+0x1d9/0x200()
[1.873722] Modules linked in:
[1.873722] Pid: 1, comm: swapper Tainted: GW 3.1.0-rc2-zurg #58
[1.8
Hi Anand,
On Wed, Aug 17, 2011 at 11:24, Anand Jain wrote:
> And a rough implementation design is here below. (As of now this does
> not include the GNOME integration since I have no idea how to do that).
Very cool idea! With regards to the Gnome integration, you might want to take
a look at wh
Hello Ken and all,
On 2011-08-17 T 19:38 +0200 Matthias G. Eckermann wrote:
> P.S.: I also added "snapper" itself there. I am not sure
> though, if it will build out of the box. ... Stay tuned.
A dinner later, the packages (.rpm/.src.rpm) for blocxx and
also snapper are available in the openSU
Chris Mason oracle.com> writes:
>
> Aside from making sure the kernel code is stable, btrfsck is all I'm
> working on right now. I do expect a release in the next two weeks that
> can recover your data (and many others).
>
> Thanks,
> Chris
> --
Chris,
We're all on the edge of our seats. C
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index 15fceef..9c1297b 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -4125,7 +4125,8 @@ static int btrfs_real_readdir(struct file *filp, void
> *dirent,
>
> /* special case for "." */
> if (filp->f_pos == 0) {
> -
(2011/08/18 11:12), Li Zefan wrote:
>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
>> index 15fceef..9c1297b 100644
>> --- a/fs/btrfs/inode.c
>> +++ b/fs/btrfs/inode.c
>> @@ -4125,7 +4125,8 @@ static int btrfs_real_readdir(struct file *filp, void
>> *dirent,
>>
>> /* special case for "
Dave,
good to have a test case on the 3.0 kernel. do you have btrfs as
root fs ? and
can you show how are you using the btrfs mainly I would need
'btrfs fi show' let me try if I can reproduce.
Thanks, Anand
I've been simply living with this issue. I can reproduce it by rsyncing very
la
This is most probably related to the same regression seen after 2.6.38,
my blocked comment on 3 August included an indication to that the
behavior was present in my distro 2.6.38 kernel too, it just was
appearing after a considerably longer uptime (on my desktop system using
btrfs as rootfs on an I
On 18/08/11 00:29, Michael Cronenworth wrote:
> I'm running kernel 3.0 (Fedora 15's 2.6.40) on two boxes
> and I have not seen slow downs or hangs. I use Firefox.
I've got btrfs on an external USB drive with the 3.0.1 kernel and
I see that sync seems to take an age, according to iotop it seems
th
Are these processes principally btrfs-submit and btrfs-transacti in
particular?
Then it may be related to my very similar issue reported earlier.
On 08/18/2011 08:47 AM, Chris Samuel wrote:
> On 18/08/11 00:29, Michael Cronenworth wrote:
>
>> I'm running kernel 3.0 (Fedora 15's 2.6.40) on two b
24 matches
Mail list logo
