on ext4?
It seems less risky to default to /boot in a new subvolume on the existing
Btrfs volume, but only GRUB2 supports and comes with another consequence
(grubby bug, will post separately).
Chris Murphy
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
/boot on ext4?
It seems less risky to support /boot in a new subvolume on the existing Btrfs
volume, but only GRUB2 supports and comes with another consequence (grubby bug,
will post separately).
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
allow access to data on working
drives. Maybe read/write is possible, but personally I'd prefer the file system
in such a degraded state to be read only. And get the surviving data off.
But I am not a Btrfs developer.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux
presently offers.
Chris Murphy--
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
? And is it possible to make a
read-writeable snapshot of a read-only subvolume?
Chris Murphy
--
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
snapshot?
In any case, for the OP, making a rw snapshot of the last backup ro snapshot,
and putting it in place of the home folder is the way to do the rollback.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
just from a consistency standpoint that seems broken.
Chris Murphy--
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 May 19, 2013, at 12:18 PM, Chris Murphy li...@colorremedies.com wrote:
It's not possible to mount regular directories with other file systems. In
some ways the btrfs subvolume behaves like a folder. In other ways it acts
like a device. If you stat the mount point for btrfs subvolumes
file system.
Chris Murphy--
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 May 20, 2013, at 7:08 PM, Duncan 1i5t5.dun...@cox.net wrote:
Chris Murphy posted on Sun, 19 May 2013 12:18:19 -0600 as excerpted:
It seems inconsistent that mount and unmount allows a /dev/ designation,
but only mount honors label and UUID.
Yes.
I'm going to contradict myself
On May 21, 2013, at 8:06 AM, Martin m_bt...@ml1.co.uk wrote:
On 21/05/13 04:37, Chris Murphy wrote:
I'm going to contradict myself and point out that mount with label or
UUID is made unambiguous via either the default subvolume being
mounted, or the -o subvol= option being specified
.
Chris Murphy--
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
if=/dev/sdc2
skip=$((245547520-33024)) seek=0 of=/dev/sdc2
You ultimately moved the wrong data because bs=4096 for dd, yet the partition
logical sectors are based on 512 bytes.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord
to specify a count
value in order to get the correct number of blocks, which would have been
732566527-245547520. Then write those blocks to sdc2 (which makes seek=
unnecessary).
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
: Can one just move a btrfs-partition to
the left by
* delete partition
* create partition moved
* dd data from old to new partition
Or does one have to adjust some references inside the btrfs filesystem?
I just did this without LUKS and it did work.
Chris Murphy--
To unsubscribe from
, was filled to the above capacity, and the other drives
were added later, so it didn't start as a RAID 0 system.
Did you balance with -dconvert raid0 when you added the additional drives?
Chris Murphy
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
system's terminal window.
https://www.kernel.org/doc/Documentation/sysrq.txt
So basically:
echo w /proc/sysrq-trigger
dmesg
Chris Murphy
--
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
of
real trouble. At the moment, this is all being done on baremetal, not within
VMs (there are no VMs yet).
Chris Murphy--
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
On Jul 13, 2013, at 2:59 PM, Chris Murphy li...@colorremedies.com wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=984236
kernel-3.10.0-1.fc20.x86_64
Should it be possible to mkfs.btrfs on a virtual LV backed by LVM thinp? I
can successfully create an XFS fs on the same virtual device
mkfs detected
[ 280.597746] btrfs: disk space caching is enabled
[ 280.661204] SELinux: initialized (dev dm-4, type btrfs), uses xattr
btrfs-progs-0.20.rc1.20130308git704a08c-1.fc19.x86_64
kernel-3.10.0-1.fc20.x86_64
Is this expected? Benign?
Chris Murphy--
To unsubscribe from this list: send
On Jul 14, 2013, at 12:13 PM, Hugo Mills h...@carfax.org.uk wrote:
On Sun, Jul 14, 2013 at 12:11:04PM -0600, Chris Murphy wrote:
On Fedora 19 with all updates, when I mkfs.btrfs and then mount the volume,
I'm getting this in dmesg:
[ 280.534868] Btrfs loaded
[ 280.581799] device fsid
On Jul 14, 2013, at 12:19 PM, Chris Murphy li...@colorremedies.com wrote:
On Jul 14, 2013, at 12:13 PM, Hugo Mills h...@carfax.org.uk wrote:
On Sun, Jul 14, 2013 at 12:11:04PM -0600, Chris Murphy wrote:
On Fedora 19 with all updates, when I mkfs.btrfs and then mount the volume,
I'm
On Jul 17, 2013, at 3:24 PM, Florian Lindner mailingli...@xgm.de wrote:
a) If one disk fails, is there any chance of data recovery?
Slim to none it seems so far. Maybe with more specialized tools.
b) If not, is there any advantage over a raid0 configuration.
raid0 allocates equal chunks,
of the surviving data. True?
Chris Murphy--
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
, or if they don't write whole files at once. And a lot of btrfs
installs don't turn on the autodefrag option when they do thet first auto-
mount to install stuff.
Some installer teams are understandably reluctant to use non-default mount
options.
Chris Murphy--
To unsubscribe from this list
would need
to be resolved or snapshotting would become useless. I'm sure there's a more
coherent explanation why this isn't desired.
That way the snapshot can share inodes with is source.
Snapshots already share inode numbers.
Chris Murphy--
To unsubscribe from this list: send the line
. A subvolume is its own tree, which can be
snapshotted and locked independantly from the other subvolumes. Thanks,
I like this, it's useful. Could it be integrated into the Wiki?
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
I must be doing something wrong, but I can't figure out what. I have
btrfs-progs source installed from here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=441375
make produces no errors. Yet btrfs-corrupt-block.c isn't built. Suggestions?
Chris Murphy--
To unsubscribe from this list
On Aug 4, 2013, at 12:46 PM, Hugo Mills h...@carfax.org.uk wrote:
On Sun, Aug 04, 2013 at 12:39:28PM -0600, Chris Murphy wrote:
I must be doing something wrong, but I can't figure out what. I have
btrfs-progs source installed from here:
http://koji.fedoraproject.org/koji/buildinfo?buildID
attempted,
and if so what were the messages recorded?
Chris Murphy--
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
common use fs has an optimization whereby just the
modified sector(s) is overwritten, rather than all sectors making up the file
system block being modified.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
with parted. I don't get it with parted or
btrfs on baremetal.
Chris Murphy--
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 Aug 10, 2013, at 10:17 AM, Chris Murphy li...@colorremedies.com wrote:
On Aug 10, 2013, at 9:42 AM, Mike Audia mike...@gmx.com wrote:
-s 16k
One answer is the drive doesn't expose a 16KB sector. It's basically lying
when it reports a 512 byte physical sector, but there isn't
multiple device volume is shrunk resized, it directly affects the
partition size which must also be changed as a separate operation right now. I
don't see Btrfs having the same granularity as LVM in this respect.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs
On Aug 16, 2013, at 12:02 PM, Chris Murphy li...@colorremedies.com wrote:
When a Btrfs multiple device volume is shrunk resized, it directly affects
the partition size…
Oops, this obviously happens with single or multiple device.
I also think the command needs to return some information
unlikely such a high percent of errors would go undetected to
result in so many uncorrectable errors, so there may be user error here along
with a bug.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
think you'd have been better off using btrfs send
and receive for this operation.
A full dmesg might also be enlightening even if it is really long. Just put it
in its own email without comment. I think pasting it out of forum is less
preferred.
Chris Murphy--
To unsubscribe from this list
On Aug 22, 2013, at 4:58 PM, Chris Murphy li...@colorremedies.com wrote:
1
2
3
4
5
6. What was the mkfs.btrfs command used? In particular are you certain the
metadata profile is default (DUP)?
7. If you have a very recent btrfs-progs (few months at most), or better if you
can build from
for all drives. And then I'd filter through dmesg to see if you have any PHY or
read errors or ATA reset messages.
Chris Murphy--
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
to come up with some steps to reproduce.
Chris Murphy--
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
of a filesystem.
Yeah I think something functionally equivalent to a combination of mdadm -D and
-E. mdadm distinguishes between array status/metadata vs member device
status/metadata with those two commands.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs
there doesn't seem to be one.
As I explained I believe btrfs has even better. It's simply that there's
no proper tools available to use it yet…
Understood.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
if you can do a balance, which should free most of those
141GB of data chunks. And then you can btrfs device delete the recently added
device, which will move whatever data/metadata chunks are on it, back to the
primary device for the volume.
Chris Murphy--
To unsubscribe from this list: send
On Aug 26, 2013, at 9:27 AM, Chris Murphy li...@colorremedies.com wrote:
I haven't tried doing a partial balance, deleting the extra device, then
finishing the balance.
Btrfs FAQ suggests a partial balance for this situation. So it's worth a try
before adding a device.
https
-recover, zero log.
Chris Murphy--
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
is how I decided to add a USB flash stick to the
volume.
Chris Murphy--
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
.
Chris Murphy
--
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 file system to a previous state, and may cause
the loss of successfully written data. Proceed? (Y/N)
Alternative language could include a suggestion or reminder of what should be
tried before proceeding, if applicable.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe
On Aug 29, 2013, at 1:40 PM, Hugo Mills h...@carfax.org.uk wrote:
On Thu, Aug 29, 2013 at 01:37:51PM -0600, Chris Murphy wrote:
Proceeding will roll back the file system to a previous state, and may
cause the loss of successfully written data. Proceed? (Y/N)
... the loss of up
On Aug 29, 2013, at 1:53 PM, Hugo Mills h...@carfax.org.uk wrote:
On Thu, Aug 29, 2013 at 01:44:54PM -0600, Chris Murphy wrote:
Certainly, if known for sure it won't be more than 30 seconds?
Mmm... it'll depend on the setting of the commit period, which up
until a couple of weeks ago
On Aug 29, 2013, at 2:19 PM, Chris Murphy li...@colorremedies.com wrote:
On Aug 29, 2013, at 1:53 PM, Hugo Mills h...@carfax.org.uk wrote:
On Thu, Aug 29, 2013 at 01:44:54PM -0600, Chris Murphy wrote:
Certainly, if known for sure it won't be more than 30 seconds?
Mmm... it'll depend
at least 2GB, or the size of the maximum
expected file size + 2GB. That way a single write operation doesn't end up
causing all free space to be allocated for data, leaving no more free space to
be allocated for metadata.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe
at it.
Otherwise, create a whole new btrfs volume with recent kernel and btrfs-progs
on the other machine; and then rsync everything from old to new. Rsync has a
checksum option, it will take longer, but you can then be reasonably assured of
file integrity.
Chris Murphy--
To unsubscribe from this list: send
-systems.btrfs/27999
I was about to suggest the same thing, but also to use something newer than
3.8.0, and before getting to any of the btrfs specific commands to make sure a
recent btrfs-progs is being used. There have been lots of fixes between 3.8 and
3.10.
Chris Murphy--
To unsubscribe from
On Aug 31, 2013, at 5:55 PM, Steven Post redalert.comman...@gmail.com wrote:
On Sat, 2013-08-31 at 11:42 -0600, Chris Murphy wrote:
Yes. It might take a few minutes after the chunks are reallocated for the
device to be removed from the volume. I've had some cases where even a
reboot
260 gen 13 top level 5 path nuts/cashew
ID 261 gen 13 top level 260 path small
The last one should be /nuts/cashew/small. Or the one before it should be
cashew instead of nuts/cashew.
Chris Murphy
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
df shows e.g. for
raid1, twice the free space as the amount of data that can be saved to the
volume.
Chris Murphy--
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
On Sep 14, 2013, at 11:05 AM, Mathew Kamkar mat...@gmail.com wrote:
Luckily, mounting the filesystem read-only,
I was able to copy all my data and rebuild the filesystem.
Did you create a new btrfs volume? Or were you somehow able to repair the old
one?
Chris Murphy
--
To unsubscribe from
=258.93MB
If this is not the result of a known bug, let me know if there's more
information I should provide, I do have a ~22MB btrfs-image -c9 -t4 of the file
system.
This fs is disposable, but I might try btrfsck --repair --init-csum-tree with a
slightly newer btrfs-progs.
Chris Murphy
there is only a single copy of each? In which case is it wise
to init-csum-tree?
Chris Murphy--
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 Sep 24, 2013, at 5:39 PM, vgrvelu vgrajan2...@gmail.com wrote:
hi
I created btrfs file system on one of sda partition. when I mount
with mount -t /dev/sda17 /btrfs,
remove the -t or add btrfs after it.
Chris Murphy
--
To unsubscribe from this list: send the line unsubscribe linux
://bugzilla.redhat.com/show_bug.cgi?id=1011714
Chris Murphy--
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
@oldlaptop ~]# btrfs fi df /
Data: total=1.01GB, used=662.47MB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=1.00GB, used=37.57MB
Metadata: total=8.00MB, used=0.00
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs
4086456643 private 0
[ 11.486405] BTRFS info (device sda4): csum failed ino 25764 off 7585792 csum
3911271769 private 0
Chris Murphy--
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
errs: wr 0, rd 0, flush 0, corrupt 17, gen 0
So somehow the corrupt counter isn't being reset?
And how would I go about setting /var/log/journal contents to inherit
nodatacow? Possible?
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
(someone logs in=journal entry, kernel reports extent
found=journal entry, kernel reports moved chunk=journal entry).
Chris Murphy--
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
On Sep 27, 2013, at 9:07 AM, Johannes Hirte johannes.hi...@datenkhaos.de
wrote:
On Tue, 24 Sep 2013 22:34:20 -0600
Chris Murphy li...@colorremedies.com wrote:
OK so I think I'm narrowing this down to just the systemd journal,
and it's not checksums that are corrupted, it's the journal
the whole file intact with just a bit flip, or bad sector data, that
has a decent change of being fixed in a supporting application. If a whole
extent is dropped, then the file is almost certainly useless. Big difference.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux
On Sep 27, 2013, at 1:13 PM, Zach Brown z...@redhat.com wrote:
On Fri, Sep 27, 2013 at 12:47:57PM -0600, Chris Murphy wrote:
On Sep 27, 2013, at 11:51 AM, Zach Brown z...@redhat.com wrote:
2) How may I tell btrfs to ignore all csums and just assume they are
all correct? The reason
scenario wasn't supported.
Chris Murphy
--
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 Sep 27, 2013, at 2:44 PM, Hugo Mills h...@carfax.org.uk wrote:
On Fri, Sep 27, 2013 at 02:12:36PM -0600, Chris Murphy wrote:
On Sep 27, 2013, at 1:36 PM, Hugo Mills h...@carfax.org.uk wrote:
When I boot the machine from its disks, I'm being told that
extlinux only supports single
Btrfs
can know about until trying to read the data back in. So *shrug* - I don't see
Btrfs as a way to totally mitigate hardware problems. It's the same problem
with bad RAM, and Btrfs doesn't like that either.
Chris Murphy
--
To unsubscribe from this list: send the line unsubscribe linux
the file system and see if there are any kernel messages
that might indicate recognition of problems with the fs.
I would not use btrfsck --repair until someone says it's a good idea. That
person would not be me.
Chris Murphy
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs
the time the delete
command was initiated.
Chris Murphy--
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 Sep 30, 2013, at 8:27 AM, Chris Murphy li...@colorremedies.com wrote:
On Sep 29, 2013, at 1:13 AM, Fredrik Tolf fred...@dolda2000.com wrote:
Is there any way I can find out what's going on?
For whatever reason, it started out with every drive practically full, in
terms of chunk
have made a different choice.
Chris Murphy
--
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
] SyS_rename+0x1b/0x20
[13616.544407] [8166d6a9] system_call_fastpath+0x16/0x1b
[13616.544409] ---[ end trace 36ebd831d74ca651 ]---
[13720.422719] BTRFS debug (device sda5): unlinked 360 orphans
[13727.309658] BTRFS debug (device sda5): unlinked 5 orphans
Chris Murphy--
To unsubscribe from
it but
doesn't have a 2nd copy of the data. Just a guess.
Chris Murphy--
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
consulted, so it would have no idea
if there's a flipped bit. The hardware ought to catch it, but we know that
isn't always true.
Chris Murphy--
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
hardware worked exactly per spec, and also didn't lie about committing
data to disk rather than merely keeping it in cache, this may be true. But
hardware lies, it has bugs. And the kernel isn't bug free either.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs
post was completely devoid of messages indicating correction.
Chris Murphy--
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
related fixes end up in 3.11.x (maybe 3.11.5).
If you aren't using a 3.11 kernel, it might be useful to know what version you
are using.
Chris Murphy--
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
On Oct 3, 2013, at 12:55 PM, Christopher Krooß c.kro...@gmail.com wrote:
On Do, 2013-10-03 at 12:50 -0600, Chris Murphy wrote:
On Oct 3, 2013, at 12:34 PM, Christopher Krooß c.kro...@gmail.com wrote:
Hi, I just encountered this kernel bug when I executed btrfs balance start
/. I'm sorry
, and
relationship to each other so this can be determined.
Does this functionality already exist?
Chris Murphy--
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
or wait for some balance fixes to get into
3.11.x and the next 3.12 rc.
Chris Murphy--
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
mode. I don't know if it's possible to convert a
degraded volume, however.
Chris Murphy
--
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 Oct 7, 2013, at 9:44 AM, Chris Murphy li...@colorremedies.com wrote:
On Oct 7, 2013, at 4:38 AM, Duncan 1i5t5.dun...@cox.net wrote:
Since your btrfs in raid1 mode has two devices currently, you won't be
able to delete one of them as-is. You will need to ADD a device first
(bringing
,
try the recovery option. Maybe you'll get different results.
Chris Murphy--
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
/Mount_options
Where as here: http://lwn.net/Articles/466493/ it's described as
Example #1, apply integrity checks to all metadata:
mount /dev/sdb1 /mnt -o check_int
Example #2, apply integrity checks to all metadata and
to data extents:
mount /dev/sdb1 /mnt -o check_int_data
Chris Murphy
]---
Chris Murphy--
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 Oct 8, 2013, at 3:58 PM, Chris Murphy li...@colorremedies.com wrote:
I don't think this is expected, is it? I can no longer move a subvolume into
another subvolume. I can move a subvolume into a directory.
So far this isn't working with 3.10.14 or 3.9.11.
The file system and subvolumes
On Oct 8, 2013, at 4:29 PM, Chris Murphy li...@colorremedies.com wrote:
So I think I need to go back to an older btrfs-progs. Or I need a new brain.
OK I'm losing it. New file system created with:
btrfs-progs-0.20.rc1.20130501git7854c8b-4.fc20.x86_64
3.11.3-301.fc20.x86_64
I still can't move
On Oct 9, 2013, at 10:27 AM, Josef Bacik jba...@fusionio.com wrote:
On Tue, Oct 08, 2013 at 03:58:23PM -0600, Chris Murphy wrote:
I don't think this is expected, is it? I can no longer move a subvolume into
another subvolume. I can move a subvolume into a directory. This happens
of F15, which were apparently* resolved with
kernel parameter clocksource=jiffies which is not related to btrfs, and was not
previously required for F14 with earlier versions of VirtualBox.
Chris Murphy
* I say apparently with a sample of 8 failures without the option and 1 success
a different fallback location:
Microsoft/Boot/bootmgfw.efi.
Nevertheless, so long as NVRAM is behaving and isn't pilfered for other
purposes, then you can specify a fallback entry there.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
the state of a file system itself isn't good. But I figure it's
probably not a serious error or there'd be mount error messages, and would
maybe only mount ro.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
On Feb 13, 2014, at 9:48 PM, Chris Murphy li...@colorremedies.com wrote:
In any case, I'm confused also if there's a real problem or not. I guess
confusion about the state of a file system itself isn't good. But I figure
it's probably not a serious error or there'd be mount error
On Feb 13, 2014, at 10:10 PM, Chris Murphy li...@colorremedies.com wrote:
On Feb 13, 2014, at 9:48 PM, Chris Murphy li...@colorremedies.com wrote:
In any case, I'm confused also if there's a real problem or not. I guess
confusion about the state of a file system itself isn't good
to know (or care) what a chunk is. I'm
much happier with Roman's suggestion of btrfs {fi,dev} usage.
Or btrfs filesystem examine, or btrfs filesystem detail, which are
semi-consistent with mdadm for obtaining similar data.
Chris Murphy--
To unsubscribe from this list: send the line unsubscribe
say it's a bug. 3.14rc3 should be out today, and might be worth a shot.
Or btrfs-next. If you try again, you only need to convert the data profile.
Also, 10 hours to balance two disks at 2.3TB seems like a long time. I'm not
sure if that's expected.
Chris Murphy
--
To unsubscribe from this list
1 - 100 of 2056 matches
Mail list logo
