-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
-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
-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,
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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'
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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.
-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.
-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/
-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
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
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
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
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
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
-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
-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
-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
-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
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
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
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
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
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
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
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
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
-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
-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
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
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
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.
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
-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
-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
-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
-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
-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
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,
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
+++
---
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
[
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
-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
-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.
-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
-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
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
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
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
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
-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
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
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
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
-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
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
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
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
-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
-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
-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)?
-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
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
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
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.
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
On 10/5/2010 7:26 AM, Tomasz Chmielewski wrote:
There is a standard df tool, but it can be a lengthy process for
filesystems with lots of files.
Maybe you mean du? df takes almost no time at all and does not care how
many files there are.
--
To unsubscribe from this list: send the line
99 matches
Mail list logo
