On Thursday 19 January 2012 17:54:37 Elsa Thomas wrote:
> I can no longer mount my Btrfs filesystem after a clean reboot.
> Before the reboot, there were errors in the syslog, but
> unfortunately I can't recover them now that the root filesystem
> won't mount.
Might be worth trying to remount rea
I can no longer mount my Btrfs filesystem after a clean reboot. Before
the reboot, there were errors in the syslog, but unfortunately I can't
recover them now that the root filesystem won't mount.
Here is a mount attempt using kernel 3.2.1 with the latest git copy of
the btrfs-progs from Josef's r
On wed, 18 Jan 2012 11:12:20 +0100, Jan Schmidt wrote:
> On 17.01.2012 21:58, Chris Mason wrote:
>> These two didn't make my first pull request just because I wanted to get
>> something out the door. I'll definitely have them in the next pull.
>
> Please, don't do that! You can't just degene
On Thu, Jan 19, 2012 at 9:02 AM, Jérôme Poulin wrote:
> I did a preemptive fsck after a RAID crash and got many errors, is
> there something I should do if everything I use works?
Probably just ignore it.
Recent kernels (e.g. 3.1 or 3.2) is smart enough to automatically fix
certain types of erro
Right, I can mount read only. Running a find command across the
filesystem, yields lots of:
[ 7775.228342] btrfs: corrupt leaf, bad key order:
block=756502351872,root=1, slot=1
type messages in dmesg, running a scrub gives:
scrub status for 7d65d152-1200-4043-981a-06757707f1ba
scrub started
I did a preemptive fsck after a RAID crash and got many errors, is
there something I should do if everything I use works?
root 412 inode 427 errors 400
root 412 inode 430 errors 400
root 412 inode 434 errors 400
root 412 inode 436 errors 400
root 412 inode 440 errors 400
root 412 inode 446 errors
First thing I'd try is to try mounting it readonly ("mount ... -o
ro"). This should get it mounted, or at least failing at a later
point with different (better?) error messages to work from. (dmesg
output after such an attempt would be useful).
On the vanilla kernel front, Ubuntu has kernel debs
I still haven't managed to fix the problem/problems, and now I cant
mount the partition. I have attached the portion from kern.log that I
think is relevant. I also tried btrfsck, but it segfaulted, the log
(btrfsck.log) is attached. When I try mounting now, the command
doesn't end.
Any tips,
Than
Hi all,
I got this kernel dump when trying to remove some files.
Now, when I try to access the directory, or any file there I get:
---
[xxx@tyler vbox]$ ls
ls: cannot access machine: Stale NFS file handle
harddisk machine
[xxx@tyler vbox]$ cd machine
bash: cd: machine: Stale NFS file handle
[xx
>
> it has comparable performance and compression ratio to snappy. Quoting
> from the source repo main page:
>
> NameRatio C.speed D.speed
> LZ4 (r41) 2.08319 1070
> LZO 2.05 1x_1 2.07318 466
> Snappy 1.0.42.02242 683
>
Although there is Less
> > I have multiple subvolumes on the same filesystem that are mounted with
> > different options in fstab.
> > The problem is the mount options for subsequent subvolume mounts seem to be
> > ignored as reflected in /proc/mounts.
>
> The output of 'mount' and /proc/mounts is different. mount tak
I have a Btrfs partition that is reliably reproducing premature ENOSPC
when restoring the disk from a tar file, but it is only happening with
zlib compression (lzo or no compression proceeds normally).
I've had the same issue at least back through the 3.1 kernel series,
and I've been having interm
We have been passing nothing but (u64)-1 to find_free_extent for search_end in
all of the callers, so it's completely useless, and we've always been passing 0
in as search_start, so just remove them as function arguments and move
search_start into find_free_extent. Thanks,
Signed-off-by: Josef Ba
This is a relic from before we had the disk space cache and it was to make
bootup times when you had btrfs as root not be so damned slow. Now that we have
the disk space cache this isn't a problem anymore and really having this code
casues uneeded fragmentation and complexity, so just remove it.
On Wed, Jan 18, 2012 at 13:41, Hugo Mills wrote:
> On Wed, Jan 18, 2012 at 11:12:20AM +0100, Jan Schmidt wrote:
>> On 17.01.2012 21:58, Chris Mason wrote:
>> > These two didn't make my first pull request just because I wanted to get
>> > something out the door. I'll definitely have them in the ne
On Wed, Jan 18, 2012 at 11:12:20AM +0100, Jan Schmidt wrote:
> On 17.01.2012 21:58, Chris Mason wrote:
> > These two didn't make my first pull request just because I wanted to get
> > something out the door. I'll definitely have them in the next pull.
>
> Please, don't do that! You can't just deg
On Tue, Jan 17, 2012 at 06:02:32PM +0800, Miao Xie wrote:
> So we'd better make the behaviour of chunk allocation correspond with space
> reservation and free space allocation, if there is no enough disk space to
> allocate RAID(RAID0, RAID1, RAID10) chunks, we degenerate the profile and try
> to a
On Tue, Jan 17, 2012 at 01:09:36PM -0600, Kyle Gates wrote:
> I have multiple subvolumes on the same filesystem that are mounted with
> different options in fstab.
> The problem is the mount options for subsequent subvolume mounts seem to be
> ignored as reflected in /proc/mounts.
The output of
On 17.01.2012 11:02, Miao Xie wrote:
> If there is no free space, the free space allocator will try to get space from
> the block group with the degenerated profile. For example, if there is no free
> space in the RAID1 block groups, the allocator will try to allocate space from
> the DUP block gro
On 17.01.2012 21:58, Chris Mason wrote:
> These two didn't make my first pull request just because I wanted to get
> something out the door. I'll definitely have them in the next pull.
Please, don't do that! You can't just degenerate to DUP when RAID1 is
out of space, that's entirely different.
With -m32, we need two casts to get from a pointer to u64. This fixes:
- btrfs_cmds.c:1138: error: cast from pointer to integer of different size
- btrfs_cmds.c:1242: error: cast from pointer to integer of different size
With -m64, sizeof gives unsigned long, so we need a cast as well to fix:
- ex
21 matches
Mail list logo