Remove unused parameter, 'eb'. Unused since introduction in
5f39d397dfbe140a14edecd4e73c34ce23c4f9ee
Updated to be rebased against current upstream.
Signed-off-by: Ross Kirk ross.k...@gmail.com
---
fs/btrfs/ctree.c | 10 +-
fs/btrfs/ctree.h |2 +-
fs/btrfs/disk-io.c |6
Remove unused parameter, 'eb'. Unused since introduction in
5f39d397dfbe140a14edecd4e73c34ce23c4f9ee
Updated to be rebased against current upstream and correct diff supplied this
time!
Signed-off-by: Ross Kirk ross.k...@gmail.com
---
fs/btrfs/ctree.c | 10 +-
fs/btrfs/ctree.h |
Internally, btrfs_header_fsid() calculates an unsigned long, but casts
it to a pointer, while all callers cast it to unsigned long again.
Committed to btrfs as fba6aa75654394fccf2530041e9451414c28084f
Signed-off-by: Ross Kirk ross.k...@gmail.com
---
cmds-chunk.c |6 ++
ctree.c |
On 9/24/13 8:02 AM, Ross Kirk wrote:
Internally, btrfs_header_fsid() calculates an unsigned long, but casts
it to a pointer, while all callers cast it to unsigned long again.
Thanks for doing this; my only nitpick is to keep
the lines under 80 cols.
Committed to btrfs as
On 9/24/13 4:07 AM, Ross Kirk wrote:
Remove unused parameter, 'eb'. Unused since introduction in
5f39d397dfbe140a14edecd4e73c34ce23c4f9ee
Updated to be rebased against current upstream.
This doesn't apply...
- write_extent_buffer(cow, root-fs_info-fsid, btrfs_(cow),
+
On 9/24/13 4:12 AM, Ross Kirk wrote:
Remove unused parameter, 'eb'. Unused since introduction in
5f39d397dfbe140a14edecd4e73c34ce23c4f9ee
Updated to be rebased against current upstream and correct diff supplied this
time!
Ah, V3 -was- awesome. Sorry for not seeing it first.
Reviewed-by:
After digging around I cannot seemingly find a clear answer on if or
when BTRFS supports the replacing of completely faulted or failed
drives while the filesystem is still online.
EG: Equivalence or BTRFS notion of the ZFS Attach/Detach/Online/Offline/
Replace features
At the moment it seems the
While running some snashot aware defrag tests I noticed I was panicing every
once and a while in key_search. This is because of the optimization that says
if we find a key at slot 0 it will be at slot 0 all the way down the rest of the
tree. This isn't the case for btrfs_search_old_slot since it
On Mon, Sep 23, 2013 at 02:54:17PM +0200, Mathieu Chouquet-Stringer wrote:
My system is configured to do FS snapshots when I upgrade packages. I
have a cron job which runs at night to delete these snapshots. Its goal
is to keep 10 snapshots maximum, one per day if possible.
This works
hi
I created btrfs file system on one of sda partition. when I mount
with mount -t /dev/sda17 /btrfs,
it is failing with wrong fs type bad option. when i see the dmesg,
mount command is searching for ext3, ext2 filesystem on sda17. but
not btrfs.
even in the man page of mount, btrfs is not
On 9/24/13 6:39 PM, vgrvelu wrote:
hi
I created btrfs file system on one of sda partition. when I mount
with mount -t /dev/sda17 /btrfs,
# mount -t /dev/sda17 /btrfs?
That doesn't work. Maybe you meant :
# mount -t btrfs /dev/sda17 /btrfs ?
it is failing with wrong fs type bad
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
Since I can now reproduce this bug on two different computers, one with SSD,
the other HDD, and scrub does not fix the csum errors with a scrub, I've filed
a bug. It's reproducible with:
kernel-3.11.1-300.fc20.x86_64
btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc20.x86_64
Bug is at:
OK so now I'm able to reproduce this with Fedora 20 alpha RC4 on a HDD, which
uses:
kernel-3.11.1-300.fc20.x86_64
btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc20.x86_64
Since it's HDD, metadata profile DUP is used. But I still get munged checksums
with balance, and the corruption isn't fixable
I'm able to reproduce this on a different drive, HDD (WDC WD5000BEVT-22ZAT0),
also with data and metadata set to single. There are no problems reported when
scrubbing before balance, and then there is corruption reported after balance.
File system is created with:
kernel-3.9.5-301.fc19.x86_64
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 itself.
[ 19.354354] systemd-journald[210]:
/var/log/journal/8e4cbfea404512ae70096c6202c9a3bf/system.journal: Journal file
corrupted, rotating.
If I set systemd
16 matches
Mail list logo
