While using btrfs as root on kernel 3.0-rc1, there was some errors (I
wasn't able to capture the error) that forced me to do hard reset.
Now during startup system drops to busybox shell because it's unable
to mount root partition.
Is there a way to recover the data, as at least grub2 was still hap
Hi,
(2011/05/31 19:16), Arne Jansen wrote:
> The following functions had a struct btrfs_root * parameter which went
> unused:
>
> btrfs_set_block_group_rw
> btrfs_destroy_delayed_refs
> btrfs_csum_data
> extent_data_ref_count
> copy_to_sk
>
> Signed-off-by: Arne Jansen
> ---
> fs/btrfs/compres
On Monday 25 April 2011 10:57:47 Li Zefan wrote:
> Currently btrfs stores the highest objectid of the fs tree, and it always
> returns (highest+1) inode number when we create a file, so inode numbers
> won't be reclaimed when we delete files, so we'll run out of inode numbers
> as we keep create/de
With xfstest 254 I can panic the box every time with the inode number caching
stuff on. This is because we clean the inodes out when we delete the subvolume,
but then we write out the inode cache which adds an inode to the subvolume inode
tree, and then when it gets evicted again the root gets add
On Tue, May 31, 2011 at 1:50 PM, Andreas Philipp
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 31.05.2011 19:40, C Anthony Risinger wrote:
>> On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas
>> wrote:
>>> 2011-05-27 13:49:52 +0200, Andreas Philipp: [...]
> Thanks, I can
Some clarifications:
> Patchset based on 'tmp' branch e6bd18d8938986c997c45f0ea95b221d4edec095.
All patches are against btrfs-progs.
The rest of rambling is about kernel code, which handles supers.
I have read what I've wrote last night (braindump of insane!)
and will try to elaborate a bit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31.05.2011 19:40, C Anthony Risinger wrote:
> On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas
> wrote:
>> 2011-05-27 13:49:52 +0200, Andreas Philipp: [...]
Thanks, I can understand that. What I don't get is how one
creates a subvol w
2011/5/30 Chris Mason :
> Ok, so I think we're blowing past the end of the page we've kmap'd. But
> I don't think that can happen without something like the patch below
> triggering:
Quick update: after rm of ~10 GB of data, I rebooted with Linus' latest
git tree, and it works (after some minutes
Hi,
On Mon, May 30, 2011 at 11:36:53AM +1000, Stephen Rothwell wrote:
> After merging the Linus' tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
>
> fs/btrfs/sysfs.c:76:26: warning: 'btrfs_root_attrs' defined but not used
> fs/btrfs/sysfs.c:97:26: warning: 'btr
both patches are pushed to
git://repo.or.cz/linux-2.6/btrfs-unstable.git #fixes
david
On Tue, May 31, 2011 at 07:08:14PM +0200, David Sterba wrote:
> commit 4cb5300bc ("Btrfs: add mount -o auto_defrag") accesses inode
> number directly while it should use the helper with the new inode
> number
On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas
wrote:
> 2011-05-27 13:49:52 +0200, Andreas Philipp:
> [...]
>> > Thanks, I can understand that. What I don't get is how one creates
>> > a subvol with a top-level other than 5. I might be missing the
>> > obvious, though.
>> >
>> > If I do:
>> >
commit 4cb5300bc ("Btrfs: add mount -o auto_defrag") accesses inode
number directly while it should use the helper with the new inode
number allocator.
Signed-off-by: David Sterba
---
fs/btrfs/file.c |2 +-
fs/btrfs/ioctl.c |7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
d
wrap checking of filesystem 'closing' flag and fix a few missing memory
barriers.
Signed-off-by: David Sterba
---
based on 'for-linus' branch of mason/btrfs-unstable.git
fs/btrfs/ctree.h|9 +
fs/btrfs/extent-tree.c |3 +--
fs/btrfs/file.c |4 ++-
On 10 April 2011 16:29, Daniel J Blueman wrote:
> When rebooting from a crash, thus during log replay on 2.6.29-rc2,
> btrfs_insert_dir_item caused an assertion failure [1]. The fs was
> being mounted clear_cache on an SSD.
On 3.0-rc1 with a fresh filesystem, after a few crashes with other
bugs,
On 05/30/2011 07:12 AM, Elric Milon wrote:
> On Monday 23 May 2011 21:51:57 Josef Bacik wrote:
>> On 05/23/2011 07:57 AM, Elric Milon wrote:
>>> On Monday 16 May 2011 18:28:49 you wrote:
On 05/16/2011 11:01 AM, Whirm wrote:
> On Monday 16 May 2011 16:11:19 Josef Bacik wrote:
>
>
>>
3/3 doesn't seem to arrive anymore, possibly due to a mail size
restriction on vger (yes, it is big). So I pushed it out to:
git://git.kernel.org/pub/scm/linux/kernel/git/arne/btrfs-unstable-arne.git
root-eliminate
Thanks,
Arne
On 31.05.2011 12:16, Arne Jansen wrote:
> This series aims to clean
btrfs_test_opt only needs fs_info from the root passed. So just pass
the fs_info directly.
Signed-off-by: Arne Jansen
---
fs/btrfs/ctree.h|2 +-
fs/btrfs/disk-io.c |8 +++---
fs/btrfs/extent-tree.c | 55 ++-
fs/btrfs/fil
The following functions had a struct btrfs_root * parameter which went
unused:
btrfs_set_block_group_rw
btrfs_destroy_delayed_refs
btrfs_csum_data
extent_data_ref_count
copy_to_sk
Signed-off-by: Arne Jansen
---
fs/btrfs/compression.c |3 +--
fs/btrfs/ctree.c| 20 +
This series aims to clean up passing of struct btrfs_root and struct
btrfs_fs_info. It first removes the root pointer from functions and macros
where it's not needed, afterwards it passes fs_info instead of root to
functions which only need root->fs_info.
It is based on 3.0-rc1.
These patches are
2011-05-27 13:49:52 +0200, Andreas Philipp:
[...]
> > Thanks, I can understand that. What I don't get is how one creates
> > a subvol with a top-level other than 5. I might be missing the
> > obvious, though.
> >
> > If I do:
> >
> > btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C
>
Hello Chris
On 30.05.2011 21:03, Chris Mason wrote:
How big is the FS?
About 100 G on a 500 G partition. I would only like to recover some
plain text files from it (source code),
I don't need the partition to be mountable again.
What command did you use to overwrite the super
block? Plea
Am 31.05.2011 10:18, schrieb Chris Mason:
> Excerpts from Sascha Biermanns's message of 2011-05-31 04:12:58 -0400:
>> Yesterday, I compiled the new kernel 3.0rc1 from git, but I never
>> successed to go over the point: "Removing old temporary files".
>> Pressing control-c let me boot on, but the pc
Excerpts from Sascha Biermanns's message of 2011-05-31 04:12:58 -0400:
> Yesterday, I compiled the new kernel 3.0rc1 from git, but I never
> successed to go over the point: "Removing old temporary files".
> Pressing control-c let me boot on, but the pc was the complete time on
> very high load. It
Yesterday, I compiled the new kernel 3.0rc1 from git, but I never
successed to go over the point: "Removing old temporary files".
Pressing control-c let me boot on, but the pc was the complete time on
very high load. It took me minutes, just to reach the tty login - and
again minutes after login in
Hi
I seem to be able to get btrfs reproducibly to
produce warnings and finally hang when running
a stress test on a ramdisk.
Testing was done using the "integration-test"
branch of btrfs-unstable. Note that I also tested
v2.6.39 and "integration-test" took much longer to
hang i.e. it is an impr
25 matches
Mail list logo
