and running a
scrub from inside.
This of course doesn't help if your VMs are Windows or legacy versions
of Linux without btrfs support. On BSD you could try ZFS.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
On Mon, 2015-09-28 at 23:16 +, Hugo Mills wrote:
> On Mon, Sep 28, 2015 at 07:11:51PM -0400, Calvin Walton wrote:
> >
> > The problem with trying to use btrfs checksums to compare two
> > different
> > files is that the blocks might not match up, if only due to
&
nt
arrangements on different machines, they're not really all that useful
for doing comparisons like you want.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
that's why
you're not seeing any additional gains over 3.5GB/s. Taking a look at
top output while the test is running might be informative.
On the other hand, if the CPU isn't saturated and the disk io isn't
saturated, then it's probably a scaling issue in btrfs, possibly
som
On Fri, 2015-08-14 at 12:30 -0400, Calvin Walton wrote:
> On Fri, 2015-08-14 at 12:16 -0300, Eduardo Bach wrote:
> > Hi all,
> >
> > This is my first email to this list, so please excuse any gaffe.
> >
> > I am in the evaluation early stages of a new storage, a
27;s built-in raid and mdadm is interesting to
see, but for the moment I'd say it's mostly expected.
One of the developers here might have some more precise information on
exactly why you're seeing such a performance difference.
As an aside, you have 192TB in RAID0? That's certa
amba,9p mentioned earlier), everything will be ok.
If you actually want to mount a filesystem from the same block device
on multiple VMs, you'll have to look into using a specially-designed
cluster filesystem like OCFS or GFS.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
t not be noticable
If you're just looking for speed, stick to single mode and let the
drive go fast.
Calvin.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
the btrfs filesystem
somewhere. For example:
mount -o subvolid=5 /dev/sda2 /mnt/btrfs
Then you can create your home directory under the top level by doing
btrfs subvolume create /mnt/btrfs/home2
--
Calvin Walton
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs&qu
ith a bunch of
data chunks that are mostly, but not completely, empty: they still
have the small files hanging around.
In this case a balance is still necessary to clean things up.
--
Calvin Walton
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body
orrect this condition.
I'd suggest updating your btrfs-progs.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
# flags 17
> [342252.264736] BTRFS info (device dm-4): found 67 extents
> [342266.630318] BTRFS info (device dm-4): found 67 extents
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> btrfs" in
> the body of a message to majord...@vger.kernel
uot;finished:1"
This should allow you to start a new scrub.
I'm not sure if this has been improved in newer versions of the btrfs-
progs.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
ime - or at the very least, writing in a striped
pattern between platters without moving the seek heads. There's
nothing you could do at the OS level which would make it faster
(besides preferring to read and write at the lower LBAs of the drive).
--
Calvin Walton
--
To unsubscribe from
en't any issues on the filesystem that the runtime
btrfs code can't handle. Don't run with --repair, at least not yet.
>
>
> I'm using kernel 3.14.
>
> Thanks!
> -Nikolaus
>
>
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
elete the old files.
It's not really possible to update the free space immediately, because
the filesystem doesn't actually know how much space would be freed! In
order to determine this number, the filesystem has to check all the
files in the subvolume - which is what btrfs-cleaner is doing.
> Also, what happens when the system crashes, and one drive has several
> hundred megabytes data more than the other one?
This shouldn't be an issue as long as you occasionally run a scrub or
balance. The scrub should find it and fix the missing data, and a
balance would just rewrite it a
ption if we can agree on this.
Instead of renaming the test suite, why not just "backronym" it to mean
something different? The letter x is used to mean "cross" in many
contexts, so "xfstests" could easily mean "cross-filesystem tests" - a
name that fits perfectly!
Only kind of joking,
Calvin.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
ross that.
The standard response on the mailing list for this issue is to
temporarily add an additional device to the filesystem (even e.g. a 4GB
USB flash drive is often enough) - this will add space to allocate a few
new chunks, allowing the balance to proceed. You can remove the extra
device aft
e that I wouldn't recommend zlib on most systems as a / filesystem -
it's slow to decompress compared to lzo, so it will cause slower boots
if your disk is reasonably fast.)
--
Calvin Walton
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body o
alent to
mount -t btrfs -o subvolid=0 /dev/sda1 /home
mount --bind /home/@home /home
except done as a single step in one mount command.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
ll attempt to
reconstruct the filesystem structure using the parity chunks instead of
data chunks and then re-check the checksum to confirm the reconstruction
was successful.
--
Calvin Walton
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of
On Mon, 2014-01-20 at 10:43 -0500, G. Michael Carter wrote:
> I'm pretty sure I know the answers but just wanted confirmation.
>
>
> RAID1: When it reads does it read from only one disk or does it try
> to read from multiple disks?
The current implementation of RAID1 on btrfs will, with a singl
ls to the
> latest even though we may be running one or two kernels behind that?...
In a recent thread on this mailing list:
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/31536
it looks like the decision made was that the latest btrfs-progs should
support older kernels.
--
Calvin Walt
+
+--+
As far as I know, there's no way to tune this at the moment.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
rtunately, the 3.11.0 kernel shipped with some outstanding bugs in
btrfs; the fixes were merged into the 3.12-rc kernels and the stable
kernel 3.11.5 or later.
Please upgrade your kernel to 3.11.5 or later!
--
Calvin Walton
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs&quo
y support
btrfs (Possibly Oracle, Red Hat, Suse? You would have to contact them
for details...) may be backporting fixes themselves.
As a result, we recommend that btrfs users should generally run whatever
the latest upstream kernel release is - in particular, you should try
the latest kernel befor
Try running "filefrag -v somefile", and compare the 'physical' and
'expected' values to look for gaps between fragments.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
les on all currently released kernels.
There's a patch available to fix this, but it hasn't been merged yet. It
might show up in 3.9 or 3.10.
You really should upgrade your kernel, however. 3.5.0 is rather old in
btrfs-years! Lots of fixes have gone into newer kernels.
--
Calvin Walton
e interesting, and people
talk about it now and then, but there is no current support in btrfs for
it.
(One thing to note: small files are often stored in the metadata area
instead of data area, which would be raid1 in your setup. As a result,
those small files are more likely to be recoverable).
-
ately. There's no provision in Linux to allow
switching out the mounted filesystem from under running applications :)
--
Calvin Walton
smime.p7s
Description: S/MIME cryptographic signature
use Mint 13, 3.2.0-30-generic 64-bit kernel.
3.2 is old! Keep in mind that given the current state of btrfs
development, fixes for btrfs are usually not backported to old stable or
longterm kernel releases, although some distributions have done so.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
elieve you can resize the underlying partition online.
There are actually some patches floating around that will allow
partitions (MBR/GPT) to be resized online, I think they're queued up to
be included in some upcoming linux release:
http://lwn.net/Articles/481141/
You still can't m
m, I'd recommend you just use a separate
> partition with ext2/4 for now.
Even with my comments, this is still my recommendation. (Although if
you're using a EFI bios, you could just stick all the bootloader stuff
on the VFAT EFI system partition instead.)
--
Calvin Walton
--
To uns
're done recovering your data (if that's
possible.)
This wouldn't have been a major problem if you had backups in the first
place :)
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
o remember :)
> >>>
> root@horus /mnt # btrfs subvolume set-default 0 test
> root@horus /mnt # umount test && mount /dev/sdb1 test
> root@horus /mnt # ls test
> sv1.file
> <<<
>
> set-default 0 seems to do nothing but does not produce an error
> e
porting cross-mount operations
on multiple mounts of the same filesystem in general? (I'd love to have
rename() work across bind mounts, for example...)
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
ike "mount --bind /mnt/subvolume/path /mnt". This used to not even
bother checking if you were attempting to mount a directory or
subvolume.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
the metadata space, which is what you're
seeing. I'm not sure if the ratio is tunable.
But better to have a bit of unused metadata space than to get 'out of
space' errors once you've filled your disk and you're trying to delete
some files!
--
Calvin Walton
--
To un
on one disk, but there are no
guarantees.
If you want data to be recoverable, you should use a redundant raid
mode; otherwise don't expect that you'll be able to save much after a
disk failure.
--
Calvin Walton
--
To unsubscribe from this list: send the line "unsubscribe l
On Wed, 2012-05-23 at 16:44 +0100, Martin wrote:
> On 23/05/12 05:19, Calvin Walton wrote:
> > On Tue, 2012-05-22 at 22:47 +0100, Martin wrote:
> >> I've got two recent examples of SSDs. Their pristine state from the
> >> manufacturer shows:
> >
> >&
.)
The benefit to doing this on the Vertex Plus is probably fairly small,
since to rewrite a block - even if the block is partially unwritten - is
still likely to require a read-modify-write cycle with an erase step.
The granularity of the erase blocks is just too big for the savings to
be very meani
dly
developed by them in-house), and Intel's Sandforce firmware has some
customizations for improved reliability, at the expense of some speed.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
On Tue, 2012-04-10 at 18:29 +0200, David Sterba wrote:
> On Tue, Apr 10, 2012 at 12:04:00PM -0400, Calvin Walton wrote:
> > On Tue, 2012-04-10 at 11:16 -0400, Josef Bacik wrote:
> > This one brings the mount time right down on my laptop, it's back to
> > around 0.5 second
On Tue, 2012-04-10 at 11:16 -0400, Josef Bacik wrote:
> On Mon, Apr 09, 2012 at 05:20:46PM -0400, Calvin Walton wrote:
> > On Mon, 2012-04-09 at 16:54 -0400, Josef Bacik wrote:
> > > On Mon, Apr 09, 2012 at 01:10:04PM -0400, Calvin Walton wrote:
> > > > On Mon, 201
On Mon, 2012-04-09 at 16:54 -0400, Josef Bacik wrote:
> On Mon, Apr 09, 2012 at 01:10:04PM -0400, Calvin Walton wrote:
> > On Mon, 2012-04-09 at 11:53 -0400, Calvin Walton wrote:
> > > Hi,
> > >
> > > I have a system that's using a dracut-generated ini
On Mon, 2012-04-09 at 11:53 -0400, Calvin Walton wrote:
> Hi,
>
> I have a system that's using a dracut-generated initramfs to mount a
> btrfs root. After upgrading to kernel 3.4.0-rc2 to test it out, I've
> noticed that the process of mounting the root filesystem takes
ships with the appropriate udev rules, which it uses to
initialize btrfs filesystems in the initramfs:
http://git.kernel.org/?p=boot/dracut/dracut.git;a=blob;f=modules.d/90btrfs/80-btrfs.rules;hb=HEAD
which would be suitable with minor modifications for use in a system
udev installation as well.
--
Calvi
. (Btrfs prints a message at
mount time when it autodetects this.) It shouldn't hurt to leave it.
Discard is handled with a separate mount option on btrfs (called
'discard'), and is disabled by default even if you have the 'ssd' option
enabled, because of the negative per
is formatted with btrfs system.
>
> Can anyone of you redirect me to that place to download the btrfsprogs
> source code.
The best way to get the btrfs-progs source is probably via git; Chris
Mason's repository for it can be found at
http://git.kernel.org/?p=linux/kernel/git/m
t;hdparm --write-sector" can remap it
quickly.)
Keep in mind, though - if you have a single reallocated sector on a
drive, it means that the drive medium is deteriorating. It's very likely
that you will have additional failures in the future, resulting in more
IO errors and lost data.
won't notice.
On the other hand, enabling defrag will cause files to be rewritten
occasionally, which will use additional write cycles on your flash
memory cells.
Unless you're experiencing performance problems, I would recommend you
leave the autodefrag option disabled on an SSD.
--
unt the "default" subvolume
mount --bind /home/home /home # Switch to the "home" subvolume
which of course succeeds if /home in your default subvolume is an empty
directory.
Hopefully this can be improved at some point :)
--
Calvin Walton
--
To unsubscribe from this
s').
The discard option is not currently automatically enabled; I think there
may have been some performance issues in certain cases with drives that
have slow trim implementations. But feel free to give it a try.
--
Calvin Walton
--
To unsubscribe from this list: send the line
On Wed, 2011-06-22 at 11:39 -0400, Josef Bacik wrote:
> On 06/22/2011 10:15 AM, Henning Rohlfs wrote:
> > On Tue, 21 Jun 2011 11:24:11 -0400, Calvin Walton wrote:
> >> On Mon, 2011-06-20 at 23:51 +0200, Henning Rohlfs wrote:
> >>> Hello,
> >>>
> >&g
chronous writes.
I think I can reproduce the issue well enough to bisect it, so I might
give that a try. It'll be slow going, though.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
e needed. The btrfs subvolume snapshot command
takes an atomic snapshot of the current subvolume state.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
rence counted, and won't be deleted until you remove the last
snapshot that references that data.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
data!
You might be able to fit 64gb if you use raid0, but only 48gb with
raid5; and only 16gb with raid1!
There isn't a single number that btrfs can report which does what you
want.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
ained on the wiki at [1].
And I just drew up a picture which I think should help explain it a bit,
too: http://www.kepstin.ca/dump/btrfs-alloc.png
If I can figure out how to add images to the btrfs wiki, and find a good
place to put it, do you think this would be a helpful addition?
> [1]
>
On Thu, 2011-03-31 at 18:59 -0400, Josef Bacik wrote:
> On Thu, Mar 31, 2011 at 05:06:42PM -0400, Calvin Walton wrote:
> > On Wed, 2011-03-30 at 17:19 -0400, Josef Bacik wrote:
> > > Hello,
> > >
> > > Just found a big bug in the free space caching stuff tha
nvenience. Thanks,
Any chance you could provide a little more information about which
kernels are affected? Is it any kernel with free space cache support (is
2.6.38.x included?) - and if so, do you plan on submitting the fix to
the stable kernel series?
--
Calvin Walton
--
To unsubscribe from this
that some will slip through.
You just have to live with it: make sure you run your own spam filters
and are careful about links in mails.
--
Calvin Walton
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
me sort of
estimation tool could be useful. (But it would be just that: an
estimate, not an exact count.)
This will get worse once btrfs supports having data with different raid
levels on the same filesystem, because you’ll have different amounts of
“available” space depending on which raid type the da
ckup), no need to "cp" anything
> - add "--inplace" to rsync
To add a bit to this: if you *do not* use the --inplace option on rsync,
rsync will rewrite the entire file, instead of updating the existing
file!
This of course negates some of the benefits of btrfs's COW s
402G 254G 145G 64% /
If you use the btrfs tool's df command to account for space in your
testing, you should get much more accurate results.
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
object id can be found using the tool
btrfs subvolume list
The subvolid= mount option was missing from the wiki, so I've just added
it:
https://btrfs.wiki.kernel.org/index.php/Getting_started#Mount_Options
--
Calvin Walton
--
To unsubscribe from this list: send the line &
ctory in the top-level volume)
Ah, this is the first I've heard that extlinux doesn't support reading
files in subvolumes. That's an unfortunate limitation :/
8<--8<-
From: Calvin Walton
Date: Sat, 27 Nov 2010 23:17:55 -0500
that'll give you an improvement:
# btrfs filesystem defragment /mountpoint/of/volume
Let us know if that helps, of course :)
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
an try bisecting it to narrow it down; let me know!
--
Calvin Walton
--
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 http://vger.kernel.org/majordomo-info.html
It's not foolproof, it's more of a warning to developers.)
If you think of it this way, memcpy is a function defined in the C
standard, there's absolutely nothing Linux-specific about using it.
Of course, IANAL; and you should probably grab some more opinions on the
matter.
--
C
filesystem shouldn't be needed, or?
Shorter term, writing a udev rule along the lines of
ENV{ID_FS_TYPE}=="btrfs", RUN+="/sbin/btrfsctl -A %N"
(put it in /etc/udev/rules.d/64-btrfs-scan.rules or so) will cause your
btrfs to be scanned when found. Possibly something like this
perror("failed to open /dev/btrfs-control");
+ exit(1);
+ }
name = fname;
} else {
fd = open_file_or_dir(fname);
--
Calvin Walton
--
To unsubscribe from this list: send the line "unsubscribe linux-btr
73 matches
Mail list logo
