Hi,
After upgrading my kernel from 2.6.38 (which has worked fine for months) to
3.1.6, I got ENOSPC on recompiling gcc (even though df says there is 16G free
of 50G; this is a raid1 setup, so in fact it's 8 of 25).
After this error, I tried to remove the compilation directory (with rm -r):
Arie Peterson wrote (ao):
After upgrading my kernel from 2.6.38 (which has worked fine for months) to
3.1.6, I got ENOSPC on recompiling gcc (even though df says there is 16G free
of 50G; this is a raid1 setup, so in fact it's 8 of 25).
After this error, I tried to remove the compilation
On Tuesday 03 January 2012 15:06:43 Sander wrote:
Maybe your snapshots take up space. Can you show 'btrfs filesystem df /' ?
Data, RAID1: total=22.72GB, used=14.73GB
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=12.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1:
Arie Peterson wrote (ao):
On Tuesday 03 January 2012 15:06:43 Sander wrote:
Maybe your snapshots take up space. Can you show 'btrfs filesystem df /' ?
Data, RAID1: total=22.72GB, used=14.73GB
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=12.00KB
System: total=4.00MB,
On Tue, Jan 3, 2012 at 8:12 AM, Arie Peterson ar...@xs4all.nl wrote:
On Tuesday 03 January 2012 15:06:43 Sander wrote:
Maybe your snapshots take up space. Can you show 'btrfs filesystem df /' ?
Data, RAID1: total=22.72GB, used=14.73GB
Data: total=8.00MB, used=0.00
System, RAID1:
Hi,
I'm running Ubuntu with kernel 2.6.38 on a fileserver system.
One of the disks in a RAID1 configuration failed (/dev/sdc), and since then
I haven't been able to access the btrfs filesystem on the remaining disk
(/dev/sdb).
root@midnite:~/src/btrfs-progs-unstable# ./btrfsck /dev/sdb
No valid
On Tuesday 03 January 2012 15:22:58 Sander wrote:
Hm, not full.
OK, I'll keep this in mind. I'm a bit anxious to reboot, because I'm
afraid booting will fail if the root file system cannot be written to.
But you did already reboot as you said the old kernel exposed the same
behavior?
I've recently run into a kernel NULL pointer dereference while
scrubbing a partition that had picked up error.
I'm running kernel 3.2.0-rc7. I'd had a power outage, and noticed an
error in a partition when running btrfsck after reboot:
# ./btrfsck /dev/sdb5
root 5 inode 19772 errors 400
found
On Tue, 2012-01-03 at 23:26 +0530, debit2...@gmail.com wrote:
Hi Everyone,
I am very new to this mailing list and very much interested in getting
into the internals of BTRFS file system
I was looking for mkfs.btrfs source code so that I can start getting
how the disk is formatted with btrfs
On Thu, Dec 29, 2011 at 12:02:48PM +0800, Li Zefan wrote:
Martin Steigerwald wrote:
Hi!
With 3.2-rc4 (probably earlier), Ext4 seems to remember what areas it
trimmed:
merkaba:~ fstrim -v /boot
/boot: 224657408 bytes were trimmed
merkaba:~ fstrim -v /boot
/boot: 0 bytes were
On Tue, Jan 3, 2012 at 8:44 AM, Dan Garton dan.gar...@gmail.com wrote:
[...]
1327 btrfs-vol -a
1328 btrfs-vol -a /nuvat
1329 btrfs-vol -a asdasd /nuvat
1330 btrfs-vol -a missing /nuvat
1331 btrfs-vol -a /dev/sdc /nuvat
1332 btrfs-vol -a /dev/sdb /nuvat
1334 btrfs-vol -a
11 matches
Mail list logo