Tag Info

Hot answers tagged

25

One obvious answer is etckeeper by Joey Hess of Debian, which manages files under /etc using version control. It supports subversion, git and mercurial.


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 ...


12

The btrfs manpage fails to document the property subcommand, which I found by grep'ing the source. It's also in btrfs --help. To set a snapshot to read-write, you do something like this: btrfs property set -ts /path/to/snapshot ro false Change that to true to set it to read-only. You can also use list to see the available properties: btrfs property ...


11

I wrote bedup for this purpose. It combines incremental btree scanning with CoW-deduplication. Best used with Linux 3.6, where you can run: sudo bedup dedup


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 ...


9

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 ...


8

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 ...


6

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 ...


6

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

No, and while fuse-ZFS is the bee's knees (having tried it) I wouldn't use it either. It's not a stability issue - both are fairly stable - but one of code maturity.


5

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 ...


5

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 ...


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 ...


5

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.


5

btrfs balance status /mountpoint man 8 btrfs [filesystem] balance status [-v] <path> Show status of running or paused balance. Options -v be verbose


5

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 ...


4

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 ...


4

Unless you specified otherwise when you formatted, the default is to store duplicate copies of the metadata blocks for improved reliability. You probably have 2gb worth of metadata that is stored twice, using 4gb. You can see more details with btrfs filesystem df.


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

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 ...


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

As someone who is using a btrfs filesystem with Arch Linux for almost 2 years now I can safely say that there does not seem to be a practical limit on the number of snapshots that can be easily reached. There are some caveats though. btrfs filesystem can lead to fragmentation. It is therefore advisable to use the online defragmentation feature built into ...


3

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. ...


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

btrfs sub snap -r fs snapshot ... do things on fs btrfs sub del fs btrfs sub snap snapshot fs btrfs sub del snapshot


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

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.



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