Re: btrfs error: 'disk full' although 8 of 21 GB free
here is the output of btrfs-debug-tree /dev/mapper/homeDevice cca 115MB http://leteckaposta.cz/file/156803395.1/02a22dde7c98235100610b24f28db4b064e7be4c or http://leteckaposta.cz/156803395 Regards, Marek -- 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
Re: btrfs error: 'disk full' although 8 of 21 GB free
On Wed, Apr 07, 2010 at 04:59:02PM +0200, Marek Otahal wrote: Hi, I'm running archlinux, kernel 2.6.33.2, btrfs-progs 0.19. I was copying a folder (cca 2GB) to a btrfs partition(8GB free) and got a 'disk full' error message. Had to kill the process and remove the files otherwise apps report full disk. I can always reproduce this by creating some big files on the partition. Since then, btrfsck reports errors, is there a way to fix them? Thank you, Mark // here follows contents of files attached for your comfort Here are some clues: *output of df -h: FilesystemSize Used Avail Use% Mounted on /dev/sda5 20G 13G 6.0G 68% / udev 10M 248K 9.8M 3% /dev none 1.0G 0 1.0G 0% /dev/shm /dev/mapper/homeDevice 21G 13G 8.0G 62% /home tmpfs 3.0G 29M 3.0G 1% /tmp /dev/sda8 3.4G 2.3G 976M 71% /var /dev/sda2 145M 20M 118M 15% /boot /dev/mapper/storeDevice 40G 38G 2.0G 96% /mnt/store /dev/sda10 18G 9.1G 7.4G 56% /mnt/recovery /dev/sda129.8G 9.6G 206M 98% /media/disk /dev/sda1 30G 22G 7.5G 75% /mnt/winxp * I've heard df has issues with btrfs, but du -sh /mountpoint reports approx same size used *btrfsck /dev/mapper/homeDevice - is there a way to fix these errors?? I'm worried to take snapshots or defragment not to make it worse. Some work has been done in this area recently. Can you run with the latest btrfs-unstable tree? Df will tell you something that is more along the lines with what you are expecting, and you can use the new btrfs-progs-unstable tree and run a btrfs filesystem df /mount/point and it will spit out specific space info that will be helpfull. Thanks, Josef -- 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
Re: btrfs error: 'disk full' although 8 of 21 GB free
I can tell you from experience that the later unstable git pull works much better in this regard. I have a 299GB filesystem compressed to 1.2TB full with 507M free. And it handles the ENOSPC condition like it should. On Wed, Apr 7, 2010 at 10:48 AM, Josef Bacik jo...@redhat.com wrote: On Wed, Apr 07, 2010 at 04:59:02PM +0200, Marek Otahal wrote: Hi, I'm running archlinux, kernel 2.6.33.2, btrfs-progs 0.19. I was copying a folder (cca 2GB) to a btrfs partition(8GB free) and got a 'disk full' error message. Had to kill the process and remove the files otherwise apps report full disk. I can always reproduce this by creating some big files on the partition. Since then, btrfsck reports errors, is there a way to fix them? Thank you, Mark // here follows contents of files attached for your comfort Here are some clues: *output of df -h: Filesystem Size Used Avail Use% Mounted on /dev/sda5 20G 13G 6.0G 68% / udev 10M 248K 9.8M 3% /dev none 1.0G 0 1.0G 0% /dev/shm /dev/mapper/homeDevice 21G 13G 8.0G 62% /home tmpfs 3.0G 29M 3.0G 1% /tmp /dev/sda8 3.4G 2.3G 976M 71% /var /dev/sda2 145M 20M 118M 15% /boot /dev/mapper/storeDevice 40G 38G 2.0G 96% /mnt/store /dev/sda10 18G 9.1G 7.4G 56% /mnt/recovery /dev/sda12 9.8G 9.6G 206M 98% /media/disk /dev/sda1 30G 22G 7.5G 75% /mnt/winxp * I've heard df has issues with btrfs, but du -sh /mountpoint reports approx same size used *btrfsck /dev/mapper/homeDevice - is there a way to fix these errors?? I'm worried to take snapshots or defragment not to make it worse. Some work has been done in this area recently. Can you run with the latest btrfs-unstable tree? Df will tell you something that is more along the lines with what you are expecting, and you can use the new btrfs-progs-unstable tree and run a btrfs filesystem df /mount/point and it will spit out specific space info that will be helpfull. Thanks, Josef -- 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 -- Andy Carlson --- Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month, The feeling of seeing the red box with the item you want in it:Priceless. -- 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
[PATCH] Btrfs: fix lockdep warning on clone ioctl
I'm no lockdep expert, but this appears to make the lockdep warning go away for the i_mutex locking in the clone ioctl. Signed-off-by: Sage Weil s...@newdream.net --- fs/btrfs/ioctl.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index c8e6470..ae2b9a0 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1530,11 +1530,11 @@ static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd, path-reada = 2; if (inode src) { - mutex_lock(inode-i_mutex); - mutex_lock(src-i_mutex); + mutex_lock_nested(inode-i_mutex, I_MUTEX_PARENT); + mutex_lock_nested(src-i_mutex, I_MUTEX_CHILD); } else { - mutex_lock(src-i_mutex); - mutex_lock(inode-i_mutex); + mutex_lock_nested(src-i_mutex, I_MUTEX_PARENT); + mutex_lock_nested(inode-i_mutex, I_MUTEX_CHILD); } /* determine range to clone */ -- 1.6.6.1 -- 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
ENOTEMPTY on rm -rf for snapshot and subvolume
Hi Everyone, Recently i created a snapshot of an existing volume which had some amount of data. Now that after creating the snapshot i have tried deleting the same snapshot. But i am getting ENOTEMPTY for rmdir. But when i see the actual files inside are deleted not the parent directory. From the code it looks like if (inode-i_size BTRFS_EMPTY_DIR_SIZE || inode-i_ino == BTRFS_FIRST_FREE_OBJECTID) return -ENOTEMPTY; Why would unlink succeeds for the files inside the directory?, yet returning ENOTEMPTY This looks odd after this, i went ahead and tried deleting the the existing volume itself same result. So i was wondering if at all this is supposed to work this way, do i need to use btrfs commands to delete subvolumes always? and their relative snapshots?. But either in that case too returning ENOTEMPTY does confuse a user a lot. Isn't it valid just by returning EPERM will explain a lot to users saying that this is a snapshot of a subvolume or a parent subvolume which is not supposed to be deleted this way. Regards -- Harshavardhana http://www.gluster.com -- 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
[PATCH] fs/btrfs: Avoid possible NULL pointer dereference for fs_devices
loop is never traversed for fs_devices NULL in volumes.c snip while (fs_devices) { . ... } /snip Dereferencing happens right after, in this case over NULL pointer. Signed-off-by: Harshavardhana har...@gluster.com --- fs/btrfs/volumes.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index b584e9a..e3d2e6b 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -1261,7 +1261,8 @@ int btrfs_rm_device(struct btrfs_root *root, char *device_path) break; fs_devices = fs_devices-seed; } - fs_devices-seed = device-fs_devices-seed; +if (fs_devices) +fs_devices-seed = device-fs_devices-seed; device-fs_devices-seed = NULL; __btrfs_close_devices(device-fs_devices); free_fs_devices(device-fs_devices); -- 1.6.6.1 -- 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