Chris Murphy lists at colorremedies.com writes:
Hmm, actually you might have found a bug.
Small typo while we're at it, below should have one l.
kernel-3.13.0-0.rc6.git0.1.fc21.x86_64
btrfs-progs-3.12-1.fc20.x86_64
Chris Murphy
Thank you muchly!
I'm kinda glad because I didn't
Hi,
I am running write-intensive (well sort of, one write every 10s)
workloads on cheap flash media which proved to be horribly unreliable.
A 32GB microSDHC card reported bad blocks after 4 days, while a usb
pen drive returns bogus data without any warning at all.
So I wonder, how would btrfs
On Thu, Jan 09, 2014 at 11:26:26AM +0100, Clemens Eisserer wrote:
Hi,
I am running write-intensive (well sort of, one write every 10s)
workloads on cheap flash media which proved to be horribly unreliable.
A 32GB microSDHC card reported bad blocks after 4 days, while a usb
pen drive returns
Some users complaint that with latest btrfs-progs, they will
fail to use send/receive. The problem is new tool will try
to use uuid tree while it dosen't work on older kernel.
Now we first check if we support uuid tree, if not we fall into
normal search as previous way.i copy most of codes from
Hi Wang,
thank you for your answer.
I am using the latest btrfs-progs with the 3.12 kernel. I don't have
access to the machine right now (it looks like it crashed :/) but I
can send the exact versions when I'm home.
Regards,
Felix
On Thu, Jan 9, 2014 at 3:10 AM, Wang Shilong
On Thu, 9 Jan 2014 18:52:38 +0800, Wang Shilong wrote:
Some users complaint that with latest btrfs-progs, they will
fail to use send/receive. The problem is new tool will try
to use uuid tree while it dosen't work on older kernel.
Now we first check if we support uuid tree, if not we fall
Hi Stefan,
On 01/09/2014 07:49 PM, Stefan Behrens wrote:
On Thu, 9 Jan 2014 18:52:38 +0800, Wang Shilong wrote:
Some users complaint that with latest btrfs-progs, they will
fail to use send/receive. The problem is new tool will try
to use uuid tree while it dosen't work on older kernel.
Now
On Thu, Jan 09, 2014 at 12:49:48PM +0100, Stefan Behrens wrote:
On Thu, 9 Jan 2014 18:52:38 +0800, Wang Shilong wrote:
Some users complaint that with latest btrfs-progs, they will
fail to use send/receive. The problem is new tool will try
to use uuid tree while it dosen't work on older
On 01/09/2014 12:06 PM, Alex wrote:
Chris Murphy lists at colorremedies.com writes:
Specify the mount point for the Btrfs file system and it will list all
subvols on that file system.
Chris Murphy--
Thank you Chris.
When I do that on my version of the 3.12 userland:
# btrfs sub list / -o
Hugo Mills posted on Thu, 09 Jan 2014 10:42:47 + as excerpted:
On Thu, Jan 09, 2014 at 11:26:26AM +0100, Clemens Eisserer wrote:
Hi,
I am running write-intensive (well sort of, one write every 10s)
workloads on cheap flash media which proved to be horribly unreliable.
A 32GB microSDHC
Steps to reproduce:
# mkfs.btrfs -f /dev/sda8
# mount /dev/sda8 /mnt
# mkdir /mnt/subvolumes
# btrfs sub create /mnt/subvolumes/subv1
# btrfs sub create /mnt/subvolumes/subv1/subv1.1
# btrfs sub list -o /mnt/subvolumes/subv1 we did not list anything
The problem is that we don't set
On 2014-01-09 07:41, Duncan wrote:
Hugo Mills posted on Thu, 09 Jan 2014 10:42:47 + as excerpted:
On Thu, Jan 09, 2014 at 11:26:26AM +0100, Clemens Eisserer wrote:
Hi,
I am running write-intensive (well sort of, one write every 10s)
workloads on cheap flash media which proved to be
On Thu, 2014-01-09 at 12:16 +, Hugo Mills wrote:
On Thu, Jan 09, 2014 at 12:49:48PM +0100, Stefan Behrens wrote:
On Thu, 9 Jan 2014 18:52:38 +0800, Wang Shilong wrote:
Some users complaint that with latest btrfs-progs, they will
fail to use send/receive. The problem is new tool will
On Thu, 2014-01-09 at 12:41 +, Duncan wrote:
Hugo Mills posted on Thu, 09 Jan 2014 10:42:47 + as excerpted:
On Thu, Jan 09, 2014 at 11:26:26AM +0100, Clemens Eisserer wrote:
Hi,
I am running write-intensive (well sort of, one write every 10s)
workloads on cheap flash media
Austin S Hemmelgarn posted on Thu, 09 Jan 2014 07:52:44 -0500 as
excerpted:
On 2014-01-09 07:41, Duncan wrote:
Hugo Mills posted on Thu, 09 Jan 2014 10:42:47 + as excerpted:
If a [btrfs ]block is read and fails its checksum, then the other
copy (in RAID-1) is checked and used if it's
Duncan,
As a silent reader of this list (for almost a year)...
As an anonymous supporter of the BAARF (Battle Against Any RAID
Four/Five/Six/ Z etc...) initiative...
I can only break my silence and applaud your frequent interventions
referring to N-Way mirroring (searching the list for the
On Thu, Jan 09, 2014 at 05:49:48PM +0100, George Eleftheriou wrote:
Duncan,
As a silent reader of this list (for almost a year)...
As an anonymous supporter of the BAARF (Battle Against Any RAID
Four/Five/Six/ Z etc...) initiative...
I can only break my silence and applaud your frequent
On Jan 9, 2014, at 9:49 AM, George Eleftheriou ele...@gmail.com wrote:
I'm really looking forward to the day that typing:
mkfs.btrfs -d raid10 -m raid10 /dev/sd[abcd]
will do exactly what is expected to do. A true RAID10 resilient in 2
disks' failure. Simple and beautiful.
How is a
On Jan 9, 2014, at 5:52 AM, Austin S Hemmelgarn ahferro...@gmail.com wrote:
Just a thought, you might consider running btrfs on top of LVM in the
interim, it isn't quite as efficient as btrfs by itself, but it does
allow N-way mirroring (and the efficiency is much better now that they
have
claiming that RAID-10 (with 2-way mirroring) is guaranteed to survive
an arbitrary 2-device failure is incorrect.
Yes, you are right. I didn't mean any 2 devices. I should have
added from different mirrors :)
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
On Thu, Jan 09, 2014 at 06:34:23PM +0100, George Eleftheriou wrote:
claiming that RAID-10 (with 2-way mirroring) is guaranteed to survive
an arbitrary 2-device failure is incorrect.
Yes, you are right. I didn't mean any 2 devices. I should have
added from different mirrors :)
If you
Hello Frank Holton,
This is a semi-automatic email about new static checker warnings.
The patch f2ee0bf65a1c: Btrfs: convert printk to btrfs_ and fix
BTRFS prefix from Dec 20, 2013, leads to the following Smatch
complaint:
fs/btrfs/super.c:298 __btrfs_panic()
error: we previously
How is a resilient 2 disk failure possible with four disk raid10?
__ ___ RAID0
__|__ __|__ ___ RAID1
| || |
AB CD
Loosing A+C / A+D / B+C / B+D is resilient.
Loosing A+B or C+D is catastrophic.
Sorry, it's my fault. In my urge to praise
On Jan 9, 2014, at 5:41 AM, Duncan 1i5t5.dun...@cox.net wrote:
Having checksumming is good, and a second
copy in case one fails the checksum is nice, but what if they BOTH do?
I'd love to have the choice of (at least) three-way-mirroring, as for me
that seems the best practical hassle/cost
On 2014-01-09 12:31, Chris Murphy wrote:
On Jan 9, 2014, at 5:52 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
Just a thought, you might consider running btrfs on top of LVM in
the interim, it isn't quite as efficient as btrfs by itself, but
it does allow N-way mirroring (and the
On 2014-01-09 13:08, Chris Murphy wrote:
On Jan 9, 2014, at 5:41 AM, Duncan 1i5t5.dun...@cox.net wrote:
Having checksumming is good, and a second
copy in case one fails the checksum is nice, but what if they BOTH do?
I'd love to have the choice of (at least) three-way-mirroring, as for me
On Jan 9, 2014, at 3:42 AM, Hugo Mills h...@carfax.org.uk wrote:
On Thu, Jan 09, 2014 at 11:26:26AM +0100, Clemens Eisserer wrote:
Hi,
I am running write-intensive (well sort of, one write every 10s)
workloads on cheap flash media which proved to be horribly unreliable.
A 32GB microSDHC
Thanks Hugo,
Since:
-- i keep daily backups
-- all 4 devices are of the same size
I think I can test it (as soon as I have some time to spend in the
transition to BTRFS) and verify your assumptions (...and get my wish)
If you have an even number of devices and all the devices are the
On Jan 9, 2014, at 11:22 AM, Austin S Hemmelgarn ahferro...@gmail.com wrote:
On 2014-01-09 13:08, Chris Murphy wrote:
On Jan 9, 2014, at 5:41 AM, Duncan 1i5t5.dun...@cox.net wrote:
Having checksumming is good, and a second
copy in case one fails the checksum is nice, but what if they BOTH
On Thu, 9 Jan 2014 11:40:20 -0700 Chris Murphy wrote:
On Jan 9, 2014, at 3:42 AM, Hugo Mills wrote:
On Thu, Jan 09, 2014 at 11:26:26AM +0100, Clemens Eisserer wrote:
Hi,
I am running write-intensive (well sort of, one write every 10s)
workloads on cheap flash media which proved to be
On Jan 9, 2014, at 12:13 PM, Kyle Gates kylega...@hotmail.com wrote:
On Thu, 9 Jan 2014 11:40:20 -0700 Chris Murphy wrote:
On Jan 9, 2014, at 3:42 AM, Hugo Mills wrote:
On Thu, Jan 09, 2014 at 11:26:26AM +0100, Clemens Eisserer wrote:
Hi,
I am running write-intensive (well sort of,
We have a race during inode init because the BTRFS_I(inode)-location is setup
after the inode hash table lock is dropped. btrfs_find_actor uses the location
field, so our search might not find an existing inode in the hash table if we
race with the inode init code.
This commit things to setup
Skip non-regular files to avoid ioctl errors while defragmenting.
They are silently ignored in recursive mode but reported as errors when
used as command-line arguments.
Signed-off-by: Pascal VITOUX vitoux.pas...@gmail.com
---
cmds-filesystem.c | 26 --
1 file changed,
I have a btrfs partition with what *sounds* like minor damage; btrfsck
--repair prints
| enabling repair mode
| Checking filesystem on /dev/sda
| UUID: ec93d2c2-7937-40f8-aaa6-
c20c9775d93a
| checking extents
| checking free space cache
| cache and super generation don't match, space cache will
I really suspect a lot of bad block issues can be avoided by monitoring
SMART data. SMART is working very well for me with btrfs formatted
drives. SMART will detect when sectors silently fail and as those
failures accumulate, SMART will warn in an obvious way that the drive in
question is at
2014/1/6 David Sterba dste...@suse.cz:
On Mon, Jan 06, 2014 at 12:02:51AM +0100, Gerhard Heift wrote:
I am currently playing with snapshots and manual deduplication of
files. During these tests I noticed the change of ctime and mtime in
the snapshot after the deduplication with
Hello,
I'm playing around with the BTRFS_IOC_SEARCH_TREE to extract the csums
of the physical blocks. During the tests some item_header had len = 0,
which indicates the buffer was to small to hold the item. I added a
printk into the kernel to get the original size of the item and it was
around
Hi George,
I really suspect a lot of bad block issues can be avoided by monitoring
SMART data. SMART is working very well for me with btrfs formatted drives.
SMART will detect when sectors silently fail and as those failures
accumulate, SMART will warn in an obvious way that the drive in
Hello Clemens,
On 01/09/2014 04:08 PM, Clemens Eisserer wrote:
Hi George,
I really suspect a lot of bad block issues can be avoided by monitoring
SMART data. SMART is working very well for me with btrfs formatted drives.
SMART will detect when sectors silently fail and as those failures
On 01/09/2014 05:06 PM, Jim Salter wrote:
On Jan 9, 2014 7:46 PM, George Mitchell geo...@chinilu.com wrote:
I would prefer that the drive, even flash media type, would
catch and resolve write failures. If it doesn't happen at the hardware
layer, according to how I understand Hugo's answer,
My wife and I won £148m on the Euromillions lottery will be donating £1.5
Million each to you and four other individuals in our ongoing charity project,
get back to us for more details on how you can receieve your donation.
See article for more info -
Hi,
I am using btrfs for my backup RAID. This had been running well for
about a year. Recently I decided the upgrade the backup server to
openSUSE 13.1. I checked all filesystems before the upgrade and
everything was clean. I had several attempts at upgrading the system,
but all failed (the
Hi Wang,
here are the versioninformation:
server log # btrfs version
Btrfs v3.12-dirty
server log # uname -a
Linux server.home 3.12.6-hardened-r3 #1 SMP Thu Jan 2 13:16:48 CET
2014 x86_64 Intel(R) Celeron(R) CPU G1610 @ 2.60GHz GenuineIntel
GNU/Linux
This should work if I understood you
43 matches
Mail list logo
