Re: Uncorrectable errors on RAID-1?

2015-01-04 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/03/2015 12:31 AM, Chris Murphy wrote: It's not a made to order hard drive industry. Maybe one day you'll be able to 3D print your own with its own specs. And wookies did not live on endor. What's your point? Sticking fingers in your ears

Re: Uncorrectable errors on RAID-1?

2014-12-30 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/29/2014 4:53 PM, Chris Murphy wrote: Get drives supporting configurable or faster recoveries. There's no way around this. Practically available right now? Sure. In theory, no. This is a broken record topic honestly. The drives under

Re: I need to P. are we almost there yet?

2014-12-30 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/29/2014 7:20 PM, ashf...@whisperpc.com wrote: Just some background data on traditional RAID, and the chances of survival with a 2-drive failure. In traditional RAID-10, the chances of surviving a 2-drive failure is 66% on a 4-drive array,

Re: I need to P. are we almost there yet?

2014-12-30 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/30/2014 06:17 PM, ashf...@whisperpc.com wrote: I believe that someone who understands the code in depth (and that may also be one of the people above) determine exactly how BTRFS implements RAID-10. I am such a person. I had a similar

Re: Uncorrectable errors on RAID-1?

2014-12-30 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/30/2014 06:58 PM, Chris Murphy wrote: Practically available right now? Sure. In theory, no. I have no idea what this means. Such drives exist, you can buy them or not buy them. I was referring to the no way around this part. Currently

Re: Uncorrectable errors on RAID-1?

2014-12-27 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/23/2014 05:09 PM, Chris Murphy wrote: The timer in /sys is a kernel command timer, it's not a device timer even though it's pointed at a block device. You need to change that from 30 to something higher to get the behavior you want. It

Re: btrfs is using 25% more disk than it should

2014-12-19 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/18/2014 9:59 AM, Daniele Testa wrote: As seen above, I have a 410GB SSD mounted at /opt/drives/ssd. On that partition, I have one single starse file, taking 302GB of space (max 315GB). The snapshots directory is completely empty. So you

Re: btrfs is using 25% more disk than it should

2014-12-19 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/19/2014 2:59 PM, Daniele Testa wrote: No, I don't have any snapshots or subvolumes. Only that single file. The file has both checksums and datacow on it. I will do chattr +C on the parent dir and re-create the file to make sure all files

Re: btrfs is using 25% more disk than it should

2014-12-19 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/19/2014 4:15 PM, Josef Bacik wrote: Please God don't turn off of checksums. Checksums are tracked in metadata anyway, they won't show up in the data accounting. Our csums are 8 bytes per block, so basic math says you are going to max out

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

2014-12-10 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/9/2014 10:10 PM, Anand Jain wrote: In the test case provided earlier who is triggering the scan ? grub-probe ? The scan is initiated by udev. grub-probe only comes into it because it is looking to /proc/mounts to find out what device is

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

2014-12-09 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/8/2014 5:25 PM, Konstantin wrote: Phillip Susi schrieb am 08.12.2014 um 15:59: The bios does not know or care about partitions. All you need is a That's only true for older BIOSs. With current EFI boards they not only care but some also

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

2014-12-08 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/7/2014 7:32 PM, Konstantin wrote: I'm guessing you are using metadata format 0.9 or 1.0, which put the metadata at the end of the drive and the filesystem still starts in sector zero. 1.2 is now the default and would not have this problem

Re: [PATCH V2][BTRFS-PROGS] Don't use LVM snapshot device

2014-12-08 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/4/2014 1:39 PM, Goffredo Baroncelli wrote: LVM snapshots are a problem for the btrfs devices management. BTRFS assumes that each device have an unique 'device UUID'. A LVM snapshot breaks this assumption. This causes a lot of problems if

Re: [PATCH V2][BTRFS-PROGS] Don't use LVM snapshot device

2014-12-08 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/8/2014 12:36 PM, Goffredo Baroncelli wrote: I like this approach, but as I wrote before, it seems that initramfs executes a btrfs dev scan (see my previoue email 'Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots'

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

2014-12-03 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/03/2014 03:24 AM, Goffredo Baroncelli wrote: I am thinking about that. Today the device discovery happens: a) when a device appears, two udev rules run btrfs dev scan device /lib/udev/rules.d/70-btrfs.rules

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

2014-12-02 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/2/2014 7:23 AM, Austin S Hemmelgarn wrote: Stupid thought, why don't we just add blacklisting based on device path like LVM has for pvscan? That isn't logic that belongs in the kernel, so that is going down the path of yanking out the device

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

2014-12-02 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/2/2014 6:54 AM, Anand Jain wrote: we have some fundamentally wrong stuff. My original patch tried to fix it. But later discovered that some external entities like systmed and boot process is using that bug as a feature and we had to revert

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

2014-12-02 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/1/2014 4:45 PM, Konstantin wrote: The bug appears also when using mdadm RAID1 - when one of the drives is detached from the array then the OS discovers it and after a while (not directly, it takes several minutes) it appears under

Re: scrub implies failing drive - smartctl blissfully unaware

2014-12-01 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2014 6:13 PM, Chris Murphy wrote: The drive will only issue a read error when its ECC absolutely cannot recover the data, hard fail. A few years ago companies including Western Digital started shipping large cheap drives, think of the

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-25 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2014 7:05 PM, Chris Murphy wrote: I'm not a hard drive engineer, so I can't argue either point. But consumer drives clearly do behave this way. On Linux, the kernel's default 30 second command timer eventually results in what look like

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-25 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2014 6:59 PM, Duncan wrote: It's not physical spinup, but electronic device-ready. It happens on SSDs too and they don't have anything to spinup. If you have an SSD that isn't handling IO within 5 seconds or so of power on, it is badly

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-22 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/21/2014 04:12 PM, Robert White wrote: Here's a bug from 2005 of someone having a problem with the ACPI IDE support... That is not ACPI emulation. ACPI is not used to access the disk, but rather it has hooks that give it a chance to diddle

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-21 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2014 5:45 PM, Robert White wrote: Nice attempt at saving face, but wrong as _always_. The CONFIG_PATA_ACPI option has been in the kernel since 2008 and lots of people have used it. If you search for ACPI ide you'll find people

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-21 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2014 6:08 PM, Robert White wrote: Well you should have _actually_ trimmed your response down to not pressing send. _Many_ motherboards have complete RAID support at levels 0, 1, 10, and five 5. A few have RAID6. Some of them even

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-20 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2014 5:25 PM, Robert White wrote: The controller, the thing that sets the ready bit and sends the interrupt is distinct from the driver, the thing that polls the ready bit when the interrupt is sent. At the bus level there are fixed

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-20 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2014 5:33 PM, Robert White wrote: That would be fake raid, not hardware raid. The LSI MegaRaid controller people would _love_ to hear more about your insight into how their battery-backed multi-drive RAID controller is fake. You should

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-19 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2014 9:40 PM, Chris Murphy wrote: It’s well known on linux-raid@ that consumer drives have well over 30 second deep recoveries when they lack SCT command support. The WDC and Seagate “green” drives are over 2 minutes apparently. This

Re: BTRFS messes up snapshot LV with origin

2014-11-19 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2014 9:54 PM, Chris Murphy wrote: Why is it silly? Btrfs on a thin volume has practical use case aside from just being thinly provisioned, its snapshots are block device based, not merely that of an fs tree. Umm... because one of the big

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-19 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2014 9:46 PM, Duncan wrote: I'm not sure about normal operation, but certainly, many drives take longer than 30 seconds to stabilize after power-on, and I routinely see resets during this time. As far as I have seen, typical drive spin up

Re: Btrfs on a failing drive

2014-11-19 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Again, please stop taking this conversation private; keep the mailing list on the Cc. On 11/19/2014 11:37 AM, Fennec Fox wrote: well ive used spinrite and its found a few sectors and they never move so obviously the drives firmware isnt dealing

Re: BTRFS messes up snapshot LV with origin

2014-11-19 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2014 1:33 PM, Chris Murphy wrote: Thin volumes are more efficient. And the user creating them doesn't have to mess around with locating physical devices or possibly partitioning them. Plus in enterprise environments with lots of storage

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-19 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2014 4:05 PM, Robert White wrote: It's cheaper, and less error prone, and less likely to generate customer returns if the generic controller chips just send init, wait a fixed delay, then request a status compared to trying to

Re: Btrfs on a failing drive

2014-11-18 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please get in the habit of using your mail client's reply-to-all button instead of reply; there is no need for us to take this conversation private. On 11/17/2014 10:15 PM, Fennec Fox wrote: snip big smartctl output i know the drive is dying and

Re: BTRFS messes up snapshot LV with origin

2014-11-18 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2014 1:16 AM, Chris Murphy wrote: If fstab specifies rootfs as UUID, and there are two volumes with the same UUID, it’s now ambiguous which one at boot time is the intended rootfs. It’s no different than the days of /dev/sdXY where X

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-18 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2014 7:08 AM, Austin S Hemmelgarn wrote: In addition to the storage controller being a possibility as mentioned in another reply, there are some parts of the drive that aren't covered by SMART attributes on most disks, most notably the

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-18 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2014 10:35 AM, Marc MERLIN wrote: Try running hdrecover on your drive, it'll scan all your blocks and try to rewrite the ones that are failing, if any: http://hdrecover.sourceforge.net/ He doesn't have blocks that are failing; he has

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-18 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2014 11:11 AM, Marc MERLIN wrote: That seems to be the case, but hdrecover will rule that part out at least. It's already ruled out: if the read failed that is what the error message would have said rather than a bad checksum. -BEGIN

Re: scrub implies failing drive - smartctl blissfully unaware

2014-11-18 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2014 1:57 PM, Chris Murphy wrote: So a.) use smartctl -l scterc to change the value below 30 seconds (300 deciseconds) with 70 deciseconds being reasonable. If the drive doesn’t support SCT commands, then b.) change the linux scsi

Re: Re: What is the vision for btrfs fs repair?

2014-11-17 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/2014 3:29 AM, Goffredo Baroncelli wrote: On 10/10/2014 12:53 PM, Bob Marley wrote: If true, maybe the closest indication we'd get of btrfs stablity is the default enabling of autorecovery. No way! I wouldn't want a default like that.

Re: Btrfs on a failing drive

2014-11-17 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/17/2014 05:55 PM, Fennec Fox wrote: well i am an arch linux user and machine owner using a failing drive its still relyable enough for me but btrfs seems not to mark bad blocks as unusable and continues to try to write to them.

Restriper documentation

2013-04-11 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks like the restriper patches got merged last year, but never documented in the man page. Could you do that? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

Re: Varying Leafsize and Nodesize in Btrfs

2012-10-11 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/2012 12:25 PM, Josef Bacik wrote: Once you cross some hardware dependant threshold (usually past 32k) you start incurring high memmove() overhead in most workloads. Like all benchmarking its good to test your workload and see what works

Re: not enough space with data raid0

2012-03-28 Thread Phillip Susi
On 3/17/2012 8:19 AM, Hugo Mills wrote: Where is the problem, how can I use the full space? You can't. btrfs requires RAID-0 to be at least two devices wide (otherwise it's not striped at all, which is the point of RAID-0). If you want to use the full capacity of both disks and don't care

Re: getdents - ext4 vs btrfs performance

2012-03-14 Thread Phillip Susi
On 3/13/2012 5:33 PM, Ted Ts'o wrote: Are you volunteering to spearhead the design and coding of such a thing? Run-time sorting is backwards compatible, and a heck of a lot easier to code and test... Do you really think it is that much easier? Even if it is easier, it is still an ugly

Re: getdents - ext4 vs btrfs performance

2012-03-13 Thread Phillip Susi
On 3/9/2012 11:48 PM, Ted Ts'o wrote: I suspect the best optimization for now is probably something like this: 1) Since the vast majority of directories are less than (say) 256k (this would be a tunable value), for directories which are less than this threshold size, the entire directory is

Re: getdents - ext4 vs btrfs performance

2012-03-13 Thread Phillip Susi
On 3/13/2012 3:53 PM, Ted Ts'o wrote: Because that would be a format change. I think a format change would be preferable to runtime sorting. What we have today is not a hash table; it's a hashed tree, where we use a fixed-length key for the tree based on the hash of the file name. Currently

Re: getdents - ext4 vs btrfs performance

2012-03-08 Thread Phillip Susi
On 2/29/2012 11:44 PM, Theodore Tso wrote: You might try sorting the entries returned by readdir by inode number before you stat them.This is a long-standing weakness in ext3/ext4, and it has to do with how we added hashed tree indexes to directories in (a) a backwards compatible way, that

Re: btrfs-raid questions I couldn't find an answer to on the wiki

2012-02-11 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2012 12:48 AM, Duncan wrote: So you see, a separate /boot really does have its uses. =:^) True, but booting from removable media is easy too, and a full livecd gives much more recovery options than the grub shell. It is the corrupted root

Re: Packed small files

2012-02-10 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/31/2012 11:46 AM, Hugo Mills wrote: So you're looking at a minimum of 413 bytes of metadata overhead for an inline file, plus the length of the filename. Also note that the file is stored in the metadata, so by default it's stored with

Re: btrfs-raid questions I couldn't find an answer to on the wiki

2012-02-10 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/31/2012 12:55 AM, Duncan wrote: Thanks! I'm on grub2 as well. It's is still masked on gentoo, but I recently unmasked and upgraded to it, taking advantage of the fact that I have two two-spindle md/raid-1s for /boot and its backup to test

Re: [PATCH] mkfs: Handle creation of filesystem larger than the first device

2012-02-08 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/26/2012 11:03 AM, Jan Kara wrote: make_btrfs() function takes a size of filesystem as an argument. It uses this value to set the size of the first device as well which is wrong for filesystems larger than this device. It results in 'attemp to

Re: [PATCH] mkfs: Handle creation of filesystem larger than the first device

2012-02-08 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/08/2012 06:20 PM, Jan Kara wrote: Thanks for your reply. I admit I was not sure what exactly size argument should be. So after looking into the code for a while I figured it should be a total size of the filesystem - or differently it

Re: Can't resize second device in RAID1

2012-01-17 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I submitted some patches a few weeks ago to fix this so you specify the device normally instead of looking up the internal devid and passing it as an undocumented prefix to the size parameter. Hopefully they can get merged sometime soon. On

Re: How long does it take to balance a 2x1TB RAID1 ?

2012-01-09 Thread Phillip Susi
On 1/6/2012 6:23 AM, Dirk Lutzebäck wrote: Hi, I have setup up a btrfs RAID1 using two 1TB drives. How long should a 'btrfs filesystem balance' take? It is running now for more than 3 days on about 30% CPU and 40% wait state. I am using stock btrfs from ubuntu 11.10 kernel 3.0.0 Not nearly

Re: [PATCH] btrfs: change resize ioctl to take device path instead of id

2012-01-09 Thread Phillip Susi
Bump. On 12/11/2011 10:12 PM, Phillip Susi wrote: The resize ioctl took an optional argument that was a string representation of the devid which you wish to resize. For the sake of consistency with the other ioctls that take a device argument, I converted this to take a device path instead

[PATCH 2/2] btrfs-progs: document --rootdir mkfs switch

2012-01-09 Thread Phillip Susi
Signed-off-by: Phillip Susi ps...@cfl.rr.com --- man/mkfs.btrfs.8.in |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in index 542e6cf..25e817b 100644 --- a/man/mkfs.btrfs.8.in +++ b/man/mkfs.btrfs.8.in @@ -12,6 +12,7

[PATCH 1/2] btrfs-progs: removed extraneous whitespace from mkfs man page

2012-01-09 Thread Phillip Susi
There were extra spaces around some of the arguments in the man page for mkfs. Signed-off-by: Phillip Susi ps...@cfl.rr.com --- man/mkfs.btrfs.8.in | 19 ++- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in index 432db1b

Re: [PATCH] Btrfs: don't panic if orphan item already exists

2011-12-14 Thread Phillip Susi
On 12/14/2011 9:58 AM, Josef Bacik wrote: There is no underlying bug, there is a shitty situation, the shitty situation Maybe my assumptions are wrong somewhere then. You add the orphan item to make sure that the truncate will be finalized even if the system crashes before the transaction

Re: [PATCH] Btrfs: don't panic if orphan item already exists

2011-12-14 Thread Phillip Susi
On 12/14/2011 10:27 AM, Josef Bacik wrote: Except consider the case that the program was written intelligently and checks for errors on truncate. So he writes 100G, truncates to 50M, and the truncate fails and he closes the file and exits. Then somewhere down the road the inode is evicted from

Re: [PATCH] Btrfs: don't panic if orphan item already exists

2011-12-14 Thread Phillip Susi
On 12/14/2011 10:46 AM, Josef Bacik wrote: file looks like its only 50m but still has 100g of extents taking up space orphan cleanup happens and the inode is truncated and the extra space is cleaned up Yes, but isn't the only reason that the i_size change actually hit the disk is because of

Re: [PATCH] Btrfs: don't panic if orphan item already exists

2011-12-13 Thread Phillip Susi
On 12/13/2011 12:55 PM, Josef Bacik wrote: I've been hitting this BUG_ON() in btrfs_orphan_add when running xfstest 269 in a loop. This is because we will add an orphan item, do the truncate, the truncate will fail for whatever reason (*cough*ENOSPC*cough*) and then we're left with an orphan

Chunk allocation size

2011-12-12 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While poking around with btrfs-gui I noticed my fs had a fair number of quite small chunks ( especially metadata ), so I started looking into how they are allocated. It appears that the current rule is to allocate: 1) At most, 10% of the total fs

Re: [PATCH] btrfs: change resize ioctl to take device path instead of id

2011-12-11 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/11/2011 10:31 PM, Li Zefan wrote: Phillip Susi wrote: The resize ioctl took an optional argument that was a string representation of the devid which you wish to resize. For the sake of consistency with the other ioctls that take a device

Re: Cloning a Btrfs partition

2011-12-08 Thread Phillip Susi
On 12/7/2011 1:49 PM, BJ Quinn wrote: What I need isn't really an equivalent zfs send -- my script can do that. As I remember, zfs send was pretty slow too in a scenario like this. What I need is to be able to clone a btrfs array somehow -- dd would be nice, but as I said I end up with the

Re: Don't prevent removal of devices that break raid reqs

2011-12-05 Thread Phillip Susi
On 11/10/2011 2:32 PM, Alexandre Oliva wrote: Instead of preventing the removal of devices that would render existing raid10 or raid1 impossible, warn but go ahead with it; the rebalancing code is smart enough to use different block group types. Should the refusal remain, so that we'd only

Re: Resize command syntax wrong?

2011-12-01 Thread Phillip Susi
On 12/1/2011 1:46 AM, Helmut Hullen wrote: balance != resize I know. p.e. Start with 1 disk with 2 GB and 1 disk with 4 GByte Fill it with 2 Gbyte data, each disk gets 1 GByte. Add a disk with 10 GByte, run balance: each disk gets about 700 MByte. That has nothing to do with resize.

Resize command syntax wrong?

2011-11-30 Thread Phillip Susi
Currently the resize command is under filesystem, and takes a path to the mounted filesystem. This seems wrong to me. Shouldn't it be under device, and take a path to a device to resize? Otherwise, how can a resize operation when you have multiple devices make any sense? -- To unsubscribe

Re: btrfs/git question.

2011-11-28 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2011 12:53 PM, Ken D'Ambrosio wrote: Seems I've picked up a wireless regression, and randomly drop my WiFi connection with more recent kernels. While I'd love to try to track down the issue, the sporadic nature makes it difficult. But I

Re: wrong / too less space on raid

2011-11-27 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/2011 08:36 PM, Miao Xie wrote: This number is just a appraised number, not rigorous. It tells us how much space we can use to make up raid0 block groups which are used to store the file data. More specifically, the available space that df

[btrfs-progs PATCH 1/2] Removed extraneous whitespace from mkfs man page

2011-11-25 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There were extra spaces around some of the arguments in the man page for mkfs. Signed-off-by: Phillip Susi ps...@cfl.rr.com - --- man/mkfs.btrfs.8.in | 19 ++- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/man

[PATCH 2/2] Document --rootdir mkfs switch

2011-11-25 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The --rootdir switch was not documented in the man page Signed-off-by: Phillip Susi ps...@cfl.rr.com - --- man/mkfs.btrfs.8.in |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8

Re: [RFC] Subvolume Quota on-disk structures and configuration

2011-11-25 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2011 04:21 AM, Arne Jansen wrote: Now that I've got a working prototype of subvolume quota, I'd like to get some feedback on the on-disk structure and the commands I intend to use. I think I've noticed a bug so far, and have one comment

Re: btrfs and load (sys)

2011-11-23 Thread Phillip Susi
On 11/23/2011 9:43 AM, krz...@gmail.com wrote: What all those btrfs benchmark does not tell you that its performance decreases (sys load increases) with growing size of btree. Creating btrfs filesystem is instantaneous because initial tree is just nothing... While something is clearly wrong,

[PATCH 1/2] Removed extraneous whitespace from mkfs man page

2011-11-23 Thread Phillip Susi
There were extra spaces around some of the arguments in the man page for mkfs. --- man/mkfs.btrfs.8.in | 19 ++- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in index 432db1b..542e6cf 100644 --- a/man/mkfs.btrfs.8.in +++

[PATCH 2/2] Document --rootdir mkfs switch

2011-11-23 Thread Phillip Susi
--- man/mkfs.btrfs.8.in |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in index 542e6cf..25e817b 100644 --- a/man/mkfs.btrfs.8.in +++ b/man/mkfs.btrfs.8.in @@ -12,6 +12,7 @@ mkfs.btrfs \- create an btrfs filesystem [

Re: [RFC] Subvolume Quota on-disk structures and configuration

2011-11-22 Thread Phillip Susi
On 11/21/2011 3:15 PM, Arne Jansen wrote: I can rebase it to the current for-linus and push it out later today. git://git.kernel.org/pub/scm/linux/kernel/git/arne/linux-btrfs.git qgroups just waiting for the replication to the mirrors... What about the btrfs-progs changes to add the

[PATCH 0/3] Show Chunks by position

2011-11-22 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2011 10:50 AM, Phillip Susi wrote: This is a nice little tool. The one suggestion that I have is that it display the actual chunks and where they are located. It seems that right now it uses the same ioctl that btrfs fi df uses

[PATCH 1/3] Changed volume_df() to return all chunks with their offsets

2011-11-22 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 volume_df() used to return a structure containing a dictionary named usage that contained 3 chunks, keyed by their usage type ( sys, meta, data ). I changed this to an array named chunks that contains one entry for every chunk found on the disk.

[PATCH 2/3] Update UsageDisplay to be capable of displaying all chunks by position

2011-11-22 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Previously the input_data to create_usage_box was assumed to be a list of 3 chunks, one of each type: data, meta, sys. Now the list can contain any number of entries and they will each be displayed. If the entries contain the key offset, then they

[PATCH 3/3] Add radio knob to show space by position or combined

2011-11-22 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The previous method was to show chunks combined by type. This knob allows the user to choose to show each individual chunk in its actual position. - --- btrfsgui/gui/usagedisplay.py | 35 --- 1 files changed, 28

Re: [RFC] Subvolume Quota on-disk structures and configuration

2011-11-21 Thread Phillip Susi
On 7/10/2011 4:21 AM, Arne Jansen wrote: btrfs qgroup limit [--exclusive] size|none qgroupid path This sets actual limits on a qgroup. If --exclusive is given, the exclusive usage is limited instead of the referenced. I don't know if there are use cases where both values need a (possibly

Re: [RFC] Subvolume Quota on-disk structures and configuration

2011-11-21 Thread Phillip Susi
On 11/21/2011 12:20 PM, Arne Jansen wrote: On 11/21/2011 05:06 PM, Phillip Susi wrote: On 7/10/2011 4:21 AM, Arne Jansen wrote: btrfs qgroup limit [--exclusive]size|noneqgroupid path btrfs qgroup limit 10g /usr That should be simple enough for the common use case. Wouldn't that make

Re: Announcing btrfs-gui

2011-11-18 Thread Phillip Susi
On 6/1/2011 7:20 PM, Hugo Mills wrote: Over the last few weeks, I've been playing with a foolish idea, mostly triggered by a cluster of people being confused by btrfs's free space reporting (df vs btrfs fi df vs btrfs fi show). I also wanted an excuse, and some code, to mess around in the

Re: [RFC] improve space utilization on off-sized raid devices

2011-11-17 Thread Phillip Susi
On 11/17/2011 7:59 AM, Arne Jansen wrote: Right you are. So you want to sacrifice stripe size for space efficiency. Why don't you just use RAID1? Instead of reducing the stripe size for the majority of writes, I'd prefer to allow RAID10 to go down to 2 disks. This should also solve it. Yes, it

Re: [PATCH 00/21] [RFC] Btrfs: restriper

2011-11-16 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/23/2011 04:01 PM, Ilya Dryomov wrote: Hello, This patch series adds an initial implementation of restriper (it's a clever name for relocation framework that allows to do selective profile changing and selective balancing with some goodies

Re: [PATCH 00/21] [RFC] Btrfs: restriper

2011-11-15 Thread Phillip Susi
On 11/15/2011 4:22 AM, Ilya Dryomov wrote: Restriper won't let you do raid1 - dup transition because dup is only allowed for a single-spindle FS, so you'll end up with error btrfs: unable to start restripe There is no way to prioritize disks during restripe. To get dup back you'll have

Re: Btrfs progs git repo on kernel.org

2011-11-15 Thread Phillip Susi
On 10/27/2011 11:27 AM, Chris Mason wrote: Hi everyone, I've pulled in Hugo's integration tree, minus the features that were not yet in the kernel. This also has a few small commits that I had queued up outside of the fsck work. Hugo, many thanks for keeping up the integration tree! Taking

Bird's eye view of relocation trees

2011-11-14 Thread Phillip Susi
Can someone give a bird's eye view of what relocation trees are and how they are used? I've been looking over the code all morning and can only see that it appears to be a normal root tree, but with a different objectid for some reason. -- To unsubscribe from this list: send the line

Re: [PATCH 00/21] [RFC] Btrfs: restriper

2011-11-14 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a fs that started with the default policy of metadata=dup. I added a second device and rebalanced, and so the metadata chunks were converted to raid1. Now I can not remove the second device because raid1 requires at least two devices. If I

Re: grub-1.99 and btrfs-only

2011-11-07 Thread Phillip Susi
On 11/5/2011 10:02 PM, Chuck Burns wrote: These are my current subvolumes: # btrfs sub list / ID 256 top level 5 path mainroot ID 257 top level 5 path home I have sub 256 set as default, and then home is mounted onto mainroot. I advise against using set-default at all. The setup Ubuntu seems

Re: understanding the tree-log

2011-11-04 Thread Phillip Susi
On 11/4/2011 1:09 AM, Liu Bo wrote: Btrfs has an expensive commit transaction, if we commit a transaction every time we fsync, the performance is not that good. Instead of this, we introduce a write-ahead log to make our fsync faster. So if you do fsync for your data, it means your data is

btrfs-tools source code

2011-10-26 Thread Phillip Susi
It still doesn't appear to have returned to kernel.org. Should that happen sometime soon, or is it available somewhere else now? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at

Where's the superblock allocation?

2011-10-26 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After a fresh mkfs.btrfs, I'm trying to understand the data structures, and I'm a little confused about what keeps the boot sector from being allocated to a file. According to the device tree, the first 4mb of the disk are mapped directly to the

Re: Snapshot rollback

2011-10-25 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/24/2011 10:04 PM, Arand Nash wrote: Btrfs is unfortunately unable to look for snapshots by name above the currently set default root (I do not know why exectly), it can however find them by id anywhere. Ok, so looking up subvols by name uses

Re: Snapshot rollback

2011-10-24 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/24/2011 01:45 AM, dima wrote: Hello Phillip, It is hard to judge without seeing your fstab and bootloader config. Maybe your / was directly in subvolid=0 without creating a separate subvolume for it (like __active in Goffredo's reply)?

Subvolume level allocation policy

2011-10-23 Thread Phillip Susi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is it ( yet? ) possible to manipulate the allocation policy on a subvolume level instead of the fs level? For example, to make / use raid1, and /home use raid0? Or to have / allocated from an ssd and /home allocated from the giant 2tb hd. -BEGIN

Re: Atomic file data replace API

2011-01-09 Thread Phillip Susi
On 01/09/2011 01:56 PM, Thomas Bellman wrote: That particular problem was solved with the introduction of the rename(2) system call in 4.2BSD a bit more than a quarter of a century ago. There is no need to introduce another, less flexible, API for doing the same thing. I'm curious if there are

Re: Atomic file data replace API

2011-01-07 Thread Phillip Susi
On 01/07/2011 09:58 AM, Chris Mason wrote: Yes and no. We have a best effort mechanism where we try to guess that since you've done this truncate and the write that you want the writes to show up quickly. But its a guess. It is a pretty good guess, and one that the NT kernel has been making

Re: What to do about subvolumes?

2010-12-02 Thread Phillip Susi
On 12/02/2010 04:49 AM, Arne Jansen wrote: What about the alternative and allocating inode numbers globally? The only problem would be with snapshots as they share the inum with the source, but one could just remap inode numbers in snapshots by sparing some bits at the top of this 64 bit field.

Re: Chunk map/control

2010-11-10 Thread Phillip Susi
On 9/22/2010 4:12 PM, Phillip Susi wrote: Is there currently a way to view and manipulate the chunks? If I understand things correctly, a new fs has a few chunks: 1) System chunk. Contains tree of trees, device tree, chunk tree. 2) Metadata chunk. Contains the directory tree

  1   2   >