Tag Info

Hot answers tagged

12

From wiki: Extent based file storage 2^64 byte == 16 EiB maximum file size Space-efficient packing of small files Space-efficient indexed directories Dynamic inode allocation Writable snapshots, read-only snapshots Subvolumes (separate internal filesystem roots) Checksums on data and metadata Compression (gzip and LZO) Integrated multiple device support ...


11

The roadmap for btrfs in Ubuntu is to have it as the default filesystem by 12.04 LTS. The likely cutover to default will be 11.04, other distributions may have more or less aggressive plans, but watching them is your best cue to the perceived stability and reliability and performance of the code.


10

For the benefits: I believe it will be mainly the backup and mirroring features. But why would you be so hasty as to think of btrfs as a filesystem ready to replace any of your current ones? Both the wiki you refer to : (...) it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle ...


8

Don't know why it's not the default, maybe so that it behaves the same as other copying utilities (rsync, cpio, pax, tar...) which have no support for it (or when files are copied across an interface that doesn't allow that (like NFS, samba, fuse file systems layers...). I was in the same situation a few years ago, and looking at GNU cp code quickly, it's ...


7

I found out the answer by asking on the mailing-list. btrfs doesn't do RAID per-volume, but rather on a per-chunk basis. The filesystem reserves "raw" space in (p.e.) 1GB chunks. Initializing the fs with raid1 means that everytime it tries to allocate a chunk, it tries to allocate a copy of this chunk on another device. This architecture allows mixed-size ...


7

The "common wisdom" of filesystem developers is that it takes some 5 years of beating to consider a filesystem stable enough for non-experimental use. BTRFS hasn't accumulated 5 years yet, so it is considered strictly for experimental use right now. If the data on the machine aren't critical, and a rigurous backup scheme is in place, go wild. Be prepared to ...


5

Secure deletion is a tough proposition on any filesystem. Unless the filesystem is very peculiar and guarantees that there aren't other copies of the file lying around, you need to clear all the free space on the device. While you are more likely to find many bits of the file on copy-on-write filesystems, even more “static” filesystems don't have this ...


5

I did a small benchmark. It only tests writes though. Test data is a Linux kernel source tree (linux-3.8), already unpacked into memory (/dev/shm/ tmpfs), so there should be as little influence as possible from the data source. I used compressible data for this test since compression with non-compressible files is nonsense regardless of encryption. Using ...


4

I can't give you a final recommendation, but I can share a few thoughts on the subject. Given that /etc is usually rather small, you might just go for a simple compressed tar-ball solution. If you hardly need to go through the history, it might be the easiest solution to set up. For me it would be to tedious to manage logical volumes just to do keep track ...


4

I asked a similar question 2 years ago. However in my case, I was only planning to copy a single device onto raid0. I eventually found a solution. At the time you couldn't convert from raid0 to raid10, but it looks like that since kernel 3.3, you can now. So that solution may work for you in the end. A problem with that approach is that it copies the ...


4

Snapshots don't do backups. Think of them as fancy set of copy-on-write hardlinks (that are consequently limited to the same btrfs partition) that you will be able to mount as a seemingly separate filesystem (in future you will be able to use different mount options for each subvolume (=snapshot) ). Only with rsync you actually copy the data. In BTRFS, ...


4

Two comments. First, try to mount by Label or UUID instead of device. Device names can sometimes change. Otherwise, btrfs requires brtfs device scan call before it knows about btrfs filesystems on your machine. I expected arch to handle this but somehow it didn't work until I created a service file for this and put it in ...


3

btrfs-gui might be what you're looking for. It doesn't do much yet, last time I tried it. You are much better off with btrfs-progs. Note that, btrfs has subvolumes, not sub-partitions. Think of them as directories, which you can create, delete, take snapshots of, assign quotas etc.


3

Firstly, we'll create the layout we want in the default subvolume: btrfs subvolume snapshot / /rootfs mkdir /snapshots Note that /rootfs will be our new root filesystem, so don't make any changes to the current one after this step. Edit /rootfs/etc/fstab to make the system use the new rootfs subvolume as root filesystem. For that, you'll need to modify ...


3

I also advise you to use other tools for benchmarking I/O than dd. Brtfs is not a traditional filesystem and being a copy-on-write and transactional filesystem, most of the operations are done in memory and not directly on the hdds. So when you issue the deletes and recreate the file, I believe it will just reuse what is has in memory. Let's not forget that ...


3

Hmmm, btrfs seems to defeat all usual shredding methods... There is a mount option called nodatacow but that doesn't seem to affect already existing files. As you already have sensible files on your disk this btrfs FAQ entry won't help you either. Then there's debugfs. It's only for ext filesystems but there's a patch for it that might work. You could use ...


3

My first guess was btrfs since the I/O processes of this file system sometimes take over. But it wouldn't explain why X locks up. Looking at the interrupts, I see this: # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 179 0 0 0 0 ...


3

openSUSE 12.1, if installed on btrfs, automatically enables tool called snapper which uses btrfs snapshotting to get snapshots of the system before installing new packages. It is well possible that these snapshots are consuming your disk space. Check out your snapshots with snapper list command. Check out this blogpost for more information about ...


3

What do you mean by "home backup scenario"? If you mean system that is backuped regulary and you can afford lost of some work (btrfs is only fs for /home without crutial data) I'd say you can try it if you feel very adventorous. If you mean fs that underlaying backup you probably need rock-stable filesystem - like ext3/4 with ultra conservative options ...


3

The redistribution of files when removing a device is transparent. I looked at the source ( a 1 Gb git clone) but I have never been able to find anything in the user-land utilities (now bundled in btrfs IIRC) to do this without actually removing (btrfs device delete) and re-adding (btrfs device add) the device. I specifically looked at mapping subvolumes to ...


3

Well this was a learning experience for me but I eventually figured it out. I'll explain my process here so that it's easier to know how to figure this stuff out on your own (BTRFS documentation, as I'm sure you found out) is relatively incomplete for the time being. At first I thought that creating the subvolume was ioctl with a handler that didn't do any ...


2

According to Btrfs wiki, read-only snapshots are available since Linux 2.6.38. So make sure you have a recent kernel. Apart from that, you should be just able to do it using ro mount option (mount -o [other-options],ro ...).


2

To help with answer: parent transid verify failed on 14265458688 wanted 464230 found 464221 Can be fixed with: $ btrfs-zero-log DEVICE NOTE: data can be lost! First try and mount with: $ btrfs -t btrfs -o recovery,nospace_cache,clear_cache DEVICE MOUNTPOINT If cant mount data like it says "bad fs": $ btrfs restore DEVICE ...


2

This behaviour is because BTRFS supports sparse files. Basically, any sufficiently long string of "empty space" (0 bits) will be stored as metadata saying "from this point to this other point is all 0s" instead of actually writing the 0s to disk. In this case, as your input stream is /dev/zero, your entire file is 0s, and thusly its actual size on disk is ...


2

One possible answer is that the remote filesystem is mounted by default with the "atime" option. Access time writes for everything that the remote rsync accesses combined with the write penalty you suffer with RAID 5 (computing parity means reading all the RAID disks before you write to one of them) could explain the I/O magnification on the remote side. ...


2

I'm not sure the disk drives write cache is going to fix the issue for you as it sounds like you are using a loop device. So there is still the page cache/file in between your Btrfs filesystem and the actual disk. The same type of issue exists for journaling filesystems detailed here for loop-AES. So when data is synced to your loop device, it may not be on ...


2

Stephane's idea can be done through btrfs builtin tools (that's why it's cool): make the old btrfs a seed device via btrfstune -S 1 /dev/device, add devices, remove the seed device, do btrfs balance start. A seed device is a read-only device that may be part of a read-writable filesystem.


2

I agree with vonbrand, btrfs is not yet to the maturity level of ext* or XFS or JFS to name a few. I would not use it on a laptop with precious data unless I have a reliable backup that can be done also on the go. Btrfs can detect corruptions but it won't do anything more than reporting the detection unless you have an available uncorrupted copy of the same ...


2

The btrfs-tools package adds an action to the initramfs to load the btrfs module. If you purge that package (sudo apt-get purge btrfs-tools), followed by an update-initramfs -ukall if the uninstallation doesn't do it already, that should go away (though I've not tested it). If it doesn't, you can always blacklist the brtfs module in /etc/modprobe.d.


2

There is no way to do that for the moment. Actually, the volume UUID is used in each node of the chunk tree. You'll have to change them in there also assuming that the headers of the chunks/device are not hashed. BTRFS was really not design to allow this kind of backup. This is really sad, but the easiest way to handle that is to use another computer. If ...



Only top voted, non community-wiki answers of a minimum length are eligible