similar to: btrfs for enterprise raid arrays

The condition can be relaxed to accept also 0 which will delete unoccupied chunks and does not need space for the actual data relocation. Until there is an automatic empty chunk reclaim, we can use this as a last resort option under enospc. CC: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: David Sterba <dsterba@suse.cz> --- Also needs progs update, but is not required for the

Hi, I''ve been looking at Btrfs and have a couple of naive questions that don''t seem to be answered on the wiki or in the articles I''ve read on the filesystem. First: discovering a file''s checksum value. Here''s the scenario: software is writing some data as a fresh file. This software happens to know (a priori) the checksum of this data; for

I''m wondering is space really freed after deleting large subvolume? Will space be immediately available to other data like other subvolumes? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi folks, For people who might be interested, here is how btrfs performs with two partitions on a single SSD drive in a RAID-1 mirror. This is on a Dell E4200 with Core 2 Duo U9300 (1.2GHz), 2GB RAM and a Samsung SSD (128GB Thin uSATA SSD). Version 1.03c ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--

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 trimmed But BTRFS does not: merkaba:~> fstrim -v / /: 4431613952 bytes were trimmed merkaba:~> fstrim -v / /: 4341846016 bytes were trimmed Is it planned to add this feature to BTRFS

On Fri 07 January 2011 08:14:17 Hubert Kario wrote: > I''d suggest at least > mkfs.btrfs -m raid1 -d raid0 /dev/sdc /dev/sdd > if you really want raid0 I don''t fully understand -m or -d. Why would this make a truer raid0 that with no options? Is it necessary to use fdisk on new drives in creating a BTRFS multi-drive array? Or is this all that''s needed: #

I realise that the hard link limit is in the queue to fix, and I read the recent thread as well as the older (october I think) thread. I just wanted to note that BackupPC *does* in fact run into the hard link limit, and its due to the dpkg configuration scripts. BackupPC hard links files with the same content together by scanning new files and linking them together, whether or not they started

Chris Mason on 10 Feb 13:17: > Excerpts from Ben Gamari''s message of 2011-02-09 21:52:20 -0500: > > Over the last several months there have been many claims regarding > > the release of the rewritten btrfsck. Unfortunately, despite > > numerous claims that it will be released Real Soon Now(c), I have > > yet to see even a repository with preliminary code. Did I

Hi, when mounting an intentionally corrupted btrfs filesystem i get the following warning and bug message. The image can be found here www.cccmz.de/~snakebyte/btrfs.2.img.bck.bz2 [ 297.406152] device fsid e14cf01de423381a-4bd40b603870018a <6>devid 2147483649 transid 9 /dev/loop0 [ 297.411937] ------------[ cut here ]------------ [ 297.412207] WARNING: at fs/btrfs/disk-io.c:805

Greetings all, I see the following issue during snap creation under IO: Transaction commit calls btrfs_start_delalloc_inodes() that locks the delalloc_inodes list, fetches the first inode, unlocks the list, triggers btrfs_alloc_delalloc_work/btrfs_queue_worker for this inode and then locks the list again. Then it checks the head of the list again. In my case, this is always exactly the same

Hello list, recently reformatted my home partition from XFS to RAID1 btrfs. I used the default options to mkfs.btrfs except for enabling raid1 for data as well as metadata. Filesystem is made up of two 1TB drives. mike@mercury (0) pts/3 ~ $ sudo btrfs filesystem show Label: none uuid: f08a8896-e03e-4064-9b94-9342fb547e47 Total devices 2 FS bytes used 888.06GB devid 1 size 931.51GB used

Hi all, are there any plans that future versions of mkfs.btrfs will do an initial pre-discard for SSDs? (AFAIK mkfs.btrfs does not do this currently) For Ext4, mke2fs does this with the -E discard option. From the mke2fs manpage: -E discard Attempt to discard blocks at mkfs time (discarding blocks initially is useful on solid state devices and sparse / thin-provisioned storage). When

Hi Chris, This is the extent of my current queue of Btrfs snapshot/subvol/commit stuff. Most of these were posted several months ago. Can be sent upstream during this merge window? Not having this functionality is becoming a bit of a roadblock for our efforts to keep the Ceph data in a consistent state. These patches are also available from

Hi, After reading through the btrfs documentation I''m curious to know if it''s possible to ever securely erase a file from a btrfs filesystem (or ZFS for that matter). On non-COW filesystems atop regular HDDs one can simply overwrite the file with zeros or random data using dd or some other tool and rest assured that the blocks which contained the sensitive information have

I think I found a bug affecting btrfs filesystems and users invoking fstrim to discard unused blocks: if I execute a `fstrim -v /` twice, the amount trimmed does not change on the 2nd invocation AND it takes just as long as the first.  Why do I think this is a bug?  When I do the same on an ext4 partition I get different behavior: the output shows 0 B trimmed and it does is instantaneously when I

If we''ve abandoned the idea of putting the number of redundant blocks into the top bits of the type bitmask (and I hope we have), then we''re fairly much there. Current code is at: git://, http://git.infradead.org/users/dwmw2/btrfs-raid56.git git://, http://git.infradead.org/users/dwmw2/btrfs-progs-raid56.git We have recovery working, as well as both full-stripe writes

An user reported that he has hit an annoying deadlock while playing with ceph based on btrfs. Current updating device tree requires space from METADATA chunk, so we -may- need to do a recursive chunk allocation when adding/updating dev extent, that is where the deadlock comes from. If we use SYSTEM metadata to update device tree, we can avoid the recursive stuff. Reported-by: Jim Schutt

Hi, We have file readahead to do asyn file read, but has no metadata readahead. For a list of files, their metadata is stored in fragmented disk space and metadata read is a sync operation, which impacts the efficiency of readahead much. The patches try to add meatadata readahead for btrfs. In btrfs, metadata is stored in btree_inode. Ideally, if we could hook the inode to a fd so we could use

Is this useful to anyone? Got this after a crash/reboot: if (block_rsv) { WARN_ON(block_rsv->size > 0); <<<<<<<<<<<<<<<<<<<<<< btrfs_free_block_rsv(root, block_rsv); } ------------[ cut here ]------------ WARNING: at fs/btrfs/inode.c:2165 btrfs_orphan_commit_root+0xcb/0xdf() Hardware name: 2429A78 Modules linked in:

Add a mount option user_subvol_rm_allowed that allows users to delete a (potentially non-empty!) subvol when they would otherwise we allowed to do an rmdir(2). We duplicate the may_delete() checks from the core VFS code to implement identical security checks (minus the directory size check). Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/ctree.h | 1 + fs/btrfs/ioctl.c |