search for: skarlato

Hello all: I have two machines with btrfs, that give me the "blocked for more than 120 seconds" message. After that I cannot write anything to disk, i am unable to unmount the btrfs filesystem and i can only reboot with sysrq-trigger. It always happens when i write many files with rsync over network. When i used 3.2rc6 it happened randomly on both machines after 50-500gb of writes.

Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now if i run some file operations like find, i get these messages. kernel is 2.6.38.5-1 on arch linux May 5 14:15:12 mail kernel: [13559.089713] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 14:15:12 mail kernel: [13559.089834] parent transid verify failed on 3062073683968 wanted 5181 found 5188

Glück Auf! I know its been discussed more then ones, but as a user I really would like to see the patch for allowing this in the kernel. Some users tested this patch successfully for weeks or months in 2 or 3 kernel versions since then, true? I''d say by creating a snapshot, it''s nothing else in the end. More then one file or tree sharing the same data on disc, or am I wrong?

Hi all, I have two multi-disk btrfs filesystems on a Arch linux 3.4.0 system. After a power failure, both filesystems refuse to mount [ 10.402284] Btrfs loaded [ 10.402714] device fsid 1e7c18a4-02d6-44b1-8eaf-c01378009cd3 devid 4 transid 65282 /dev/sdc [ 10.403108] btrfs: force zlib compression [ 10.403130] btrfs: enabling inode map caching [ 10.403152] btrfs: disk space caching is

Hi All, the following patches implement the recursively snapshotting and deleting of a subvolume. To snapshot recursively you must pass the -R switch: # btrfs subvolume create sub1 Create subvolume ''./sub1'' # btrfs subvolume create sub1/sub2 Create subvolume ''sub1/sub2'' # btrfs subvolume snapshot -R sub1 sub1-snap Create a snapshot of

Hi, My company is testing btrfs (kernel 2.6.38) on a slave MySQL database server with a 195Gb filesystem (of which about 123Gb is used). So far, we''re quite impressed with the performance. Our database loads are high, and if filesystem performance wasn''t good, MySQL replication wouldn''t be able to keep up and the slave latency would begin to climb. This though, is

According to https://github.com/g2p/bedup/tree/wip/dedup-syscall "The clone call is considered a write operation and won''t work on read-only snapshots." Is this fixed on newer kernels? -- 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