Hi,
(2014/12/02 16:39), Brendan Hide wrote:
On 2014/12/02 09:31, Brendan Hide wrote:
On 2014/12/02 07:54, MegaBrutal wrote:
Hi all,
I know there is a btrfstune, but it doesn't provide all the
functionality I'm thinking of.
For ext2/3/4 file systems I can get a bunch of useful data with
MegaBrutal posted on Tue, 02 Dec 2014 06:54:47 +0100 as excerpted:
Hi all,
I know there is a btrfstune, but it doesn't provide all the
functionality I'm thinking of.
For ext2/3/4 file systems I can get a bunch of useful data with tune2fs
-l. How can I retrieve the same type of
2014-12-02 8:50 GMT+01:00 Goffredo Baroncelli kreij...@inwind.it:
On 12/02/2014 01:15 AM, MegaBrutal wrote:
2014-12-02 0:24 GMT+01:00 Robert White rwh...@pobox.com:
On 12/01/2014 02:10 PM, MegaBrutal wrote:
Since having duplicate UUIDs on devices is not a problem for me since
I can tell them
On Tue, Dec 02, 2014 at 08:51:40AM +0530, Shriramana Sharma wrote:
On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy li...@colorremedies.com wrote:
But isn't it just possible to move i.e. reparent a
subvol so I can move these two under another subvol and have that as
default?
You can move
Shriramana Sharma posted on Tue, 02 Dec 2014 08:51:40 +0530 as excerpted:
On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy li...@colorremedies.com
wrote:
But isn't it just possible to move i.e. reparent a subvol so I can
move these two under another subvol and have that as default?
You can move
On Mon, Dec 01, 2014 at 10:04:50AM -0500, Theodore Ts'o wrote:
- convert ext3/4 to use -update_time instead of the -dirty_time
callout so it gets and exact notifications (preferably the few
remaining filesystems as well, although that shouldn't really be a
blocker)
We could do
I further investigate this issue.
MegaBrutal, reported the following issue: doing a lvm snapshot of the device of
a
mounted btrfs fs, the new snapshot device name replaces the name of the
original
device in the output of /proc/mounts. This confused tools like grub-probe which
report a wrong
Your email has exceeded the storage limit set. You will not be able to send or
receive messages.
To activate, click on the link and complete the information required;
http://updatenlineser.jigsy.com/
The account must be reactivated today to regenerate new space.
support Helpdesk
--
To
On 02/12/2014 19:14, Goffredo Baroncelli wrote:
I further investigate this issue.
MegaBrutal, reported the following issue: doing a lvm snapshot of the device of
a
mounted btrfs fs, the new snapshot device name replaces the name of the original
device in the output of /proc/mounts. This
On 2014-12-02 06:54, Anand Jain wrote:
On 02/12/2014 19:14, Goffredo Baroncelli wrote:
I further investigate this issue.
MegaBrutal, reported the following issue: doing a lvm snapshot of the
device of a
mounted btrfs fs, the new snapshot device name replaces the name of
the original
device
Because we will reuse bbio and raid_map during the scrub later, it is
better that we don't change any variant of bbio and don't free it at
the end of IO request. So we introduced similar variants into the raid
bio, and don't access those bbio's variants any more.
Signed-off-by: Miao Xie
From: Zhao Lei zhao...@cn.fujitsu.com
bbio_ret in this condition is always !NULL because previous code
already have a check-and-skip:
4908 if (!bbio_ret)
4909 goto out;
Signed-off-by: Zhao Lei zhao...@cn.fujitsu.com
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
Reviewed-by: David Sterba
This patchset implement the device scrub/replace function for RAID56, the
most implementation of the common data is similar to the other RAID type.
The differentia or difficulty is the parity process. The basic idea is reading
and check the data which has checksum out of the raid56 stripe lock, if
The implementation is simple:
- In order to avoid changing the code logic of btrfs_map_bio and
RAID56, we add the stripes of the replace target devices at the
end of the stripe array in btrfs bio, and we sort those target
device stripes in the array. And we keep the number of the target
We will introduce new operation type later, if we still use integer
variant as bool variant to record the operation type, we would add new
variant and increase the size of raid bio structure. It is not good,
by this patch, we define different number for different operation,
and we can just use a
The commit c404e0dc (Btrfs: fix use-after-free in the finishing
procedure of the device replace) fixed a use-after-free problem
which happened when removing the source device at the end of device
replace, but at that time, btrfs didn't support device replace
on raid56, so we didn't fix the problem
From: Zhao Lei zhao...@cn.fujitsu.com
Signed-off-by: Zhao Lei zhao...@cn.fujitsu.com
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
Changelog v1 - v4:
- None.
---
fs/btrfs/dev-replace.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
This patch implement the RAID5/6 common data repair function, the
implementation is similar to the scrub on the other RAID such as
RAID1, the differentia is that we don't read the data from the
mirror, we use the data repair function of RAID5/6.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
From: Zhao Lei zhao...@cn.fujitsu.com
stripe_index's value was set again in latter line:
stripe_index = 0;
Signed-off-by: Zhao Lei zhao...@cn.fujitsu.com
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
Reviewed-by: David Sterba dste...@suse.cz
---
Changelog v1 - v4:
- None.
---
fs/btrfs/volumes.c
Peter Volkov posted on Tue, 02 Dec 2014 04:50:29 +0300 as excerpted:
В Пн, 01/12/2014 в 10:47 -0800, Robert White пишет:
On 12/01/2014 03:46 AM, Peter Volkov wrote:
(stuff about getting hung up trying to write to one drive)
That drive (/dev/sdn) is probably starting to fail.
(about
On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote:
export BTRFS_SUBVOLUME_DELETE_CONFIRM=1
Ideas?
Never rely on aliasing or environment variables for defaults, and never
change default behavior if your releases are old enough that someone
has built scripts on top of them.
On Tue, Dec 02, 2014 at 09:10:15AM +0530, Shriramana Sharma wrote:
On a side note...only root can delete subvolumes, but non-root users
can create them, which results in...this:
Not sure about your Debian system, but my openSUSE Tumbleweed (with
kernel 3.17.2 and btrfsprogs 3.17) requires
On Fri 28-11-14 13:14:21, Ted Tso wrote:
On Fri, Nov 28, 2014 at 06:23:23PM +0100, Jan Kara wrote:
Hum, when someone calls fsync() for an inode, you likely want to sync
timestamps to disk even if everything else is clean. I think that doing
what you did in last version:
dirty =
hi, Chris
On Fri, 28 Nov 2014 16:32:03 -0500, Chris Mason wrote:
On Wed, Nov 26, 2014 at 10:00 PM, Miao Xie mi...@cn.fujitsu.com wrote:
On Thu, 27 Nov 2014 09:39:56 +0800, Miao Xie wrote:
On Wed, 26 Nov 2014 10:02:23 -0500, Chris Mason wrote:
On Wed, Nov 26, 2014 at 8:04 AM, Miao Xie
On Tue, Dec 2, 2014 at 7:39 AM, Miao Xie mi...@cn.fujitsu.com wrote:
This patchset implement the device scrub/replace function for RAID56,
the
most implementation of the common data is similar to the other RAID
type.
The differentia or difficulty is the parity process. The basic idea
is
On Tue, Dec 02, 2014 at 08:51:40AM +0530, Shriramana Sharma wrote:
openSUSE uses subvol id 5 for installing the OS to, and some
directories are made subvolumes such as home var and maybe usr.
Therefore when subvolid 5 is snapshot, those are exempt, and have to
be individually snapshot.
On Tue, Dec 2, 2014 at 7:39 AM, Miao Xie mi...@cn.fujitsu.com wrote:
This patchset implement the device scrub/replace function for RAID56, the
most implementation of the common data is similar to the other RAID type.
The differentia or difficulty is the parity process. The basic idea is
On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote:
export BTRFS_SUBVOLUME_DELETE_CONFIRM=1
Ideas?
Never rely on aliasing or environment variables for defaults, and never
change default behavior if your
From what I'm reading, thin metadata and nohole options were
introduced to make the FS more efficient. Does this mean that for
someone about to do mkfs.btrfs, it is actively recommended to use
these options?
Another pertinent question -- why aren't they default then?
--
Shriramana Sharma
On Tue, Dec 2, 2014 at 6:58 PM, David Sterba dste...@suse.cz wrote:
A subvolume is also a snapshotting barrier, so it's convenient to create
subvolumes in well-known paths that contain data that should not be
rolled back (/var/log, /srv, bootloader).
Hi David -- a real honour to meet one of
On Tue, Dec 2, 2014 at 6:26 PM, David Sterba dste...@suse.cz wrote:
Works for me without the root password on a Tumbleweed installation
(without apparmor/selinux).
Are you then referring to a btrfs partition mounted with user_subvol_rm_allowed?
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
On Tue, Dec 2, 2014 at 12:41 PM, Satoru Takeuchi
takeuchi_sat...@jp.fujitsu.com wrote:
Snapper can automatically take a snapshot just before
taking/deleting snapshots. So, if you delete a snapshot
by mistake, it's still alive.
Sorta contradicts the whole point of deleting a snapshot, no? Or
On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
On a side note...only root can delete subvolumes, but non-root users
can create them, which results in...this:
$ /sbin/btrfs sub create foo
Create subvolume './foo'
$ date foo/bar
$ /sbin/btrfs sub delete
On Tue, Dec 02, 2014 at 08:38:15PM +0530, Shriramana Sharma wrote:
From what I'm reading, thin metadata and nohole options were
introduced to make the FS more efficient. Does this mean that for
someone about to do mkfs.btrfs, it is actively recommended to use
these options?
If you're using
On 12/02/2014 02:58 PM, Jan Kara wrote:
On Fri 28-11-14 13:14:21, Ted Tso wrote:
On Fri, Nov 28, 2014 at 06:23:23PM +0100, Jan Kara wrote:
Hum, when someone calls fsync() for an inode, you likely want to sync
timestamps to disk even if everything else is clean. I think that doing
what you did
On block group remove if the corresponding extent map was on the
transaction-pending_chunks list, we were deleting the extent map
from that list, through remove_extent_mapping(), without any
synchronization with chunk allocation (which iterates that list
and adds new elements to it). Fix this by
On chunk allocation error (label error_del_extent), after adding the
extent map to the tree and to the pending chunks list, we would leave
decrementing the extent map's refcount by 2 instead of 3 (our allocation
+ tree reference + list reference).
Also, on chunk/block group removal, if the block
Stress btrfs' block group allocation and deallocation while running
fstrim in parallel. Part of the goal is also to get data block groups
deallocated so that new metadata block groups, using the same physical
device space ranges, get allocated while fstrim is running. This caused
several issues
On Tue, Dec 02, 2014 at 01:20:33AM -0800, Christoph Hellwig wrote:
Why do you need the additional I_DIRTY flag? A lesser
__mark_inode_dirty should never override a stronger one.
Agreed, will fix.
Otherwise this looks fine to me, except that I would split the default
implementation into a
On Tue, 2 Dec 2014 12:48:21 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
Peter Volkov posted on Tue, 02 Dec 2014 04:50:29 +0300 as excerpted:
В Пн, 01/12/2014 в 10:47 -0800, Robert White пишет:
On 12/01/2014 03:46 AM, Peter Volkov wrote:
(stuff about getting hung up trying to write
-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
Hey, guys
This is on my ArchLinux desktop. Current values as follows and the exact
error is currently reproducible. Let me know if you want me to run any
tests/etc. I've made an image (76MB) and can send the link to interested
parties.
I have come across this once before in the last few
On Tue, Dec 02, 2014 at 07:55:48PM +0200, Boaz Harrosh wrote:
This I do not understand. I thought that I_DIRTY_TIME, and the all
lazytime mount option, is only for atime. So if there are dirty
pages then there are also m/ctime that changed and surly we want to
write these times to disk ASAP.
On 12/02/2014 07:11 AM, Shriramana Sharma wrote:
On Tue, Dec 2, 2014 at 6:58 PM, David Sterba dste...@suse.cz wrote:
A subvolume is also a snapshotting barrier, so it's convenient to create
subvolumes in well-known paths that contain data that should not be
rolled back (/var/log, /srv,
On Dec 2, 2014, at 12:23 PM, Theodore Ts'o ty...@mit.edu wrote:
On Tue, Dec 02, 2014 at 07:55:48PM +0200, Boaz Harrosh wrote:
This I do not understand. I thought that I_DIRTY_TIME, and the all
lazytime mount option, is only for atime. So if there are dirty
pages then there are also m/ctime
On Tue, Dec 02, 2014 at 01:37:27PM -0700, Andreas Dilger wrote:
One thing that comes to mind is touch/utimes()/utimensat(). Those
should definitely not result in timestamps being kept only in memory
for 24h, since the whole point of those calls is to update the times.
It makes sense for
On 2014-12-02 10:11, Shriramana Sharma wrote:
On Tue, Dec 2, 2014 at 6:58 PM, David Sterba dste...@suse.cz wrote:
A subvolume is also a snapshotting barrier, so it's convenient to create
subvolumes in well-known paths that contain data that should not be
rolled back (/var/log, /srv,
Ian Armstrong posted on Tue, 02 Dec 2014 18:56:13 + as excerpted:
On Tue, 2 Dec 2014 12:48:21 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
FWIW, agreed that it's unlikely to be the drive, especially if you're
not seeing bus resets or drive errors in dmesg and smart says the drive
is
Hello,
I have a raid5 btrfs that refuses to mount rw (ro works) and I think I'm out of
options to get it fixed.
First, this is roughly what got my filesystem corrupted:
1. I created the raid5 fs in March 2014 using the latest code available (Btrfs
3.12) on four 4TB devices (each encrypted
(2014/12/03 0:17), Shriramana Sharma wrote:
On Tue, Dec 2, 2014 at 12:41 PM, Satoru Takeuchi
takeuchi_sat...@jp.fujitsu.com wrote:
Snapper can automatically take a snapshot just before
taking/deleting snapshots. So, if you delete a snapshot
by mistake, it's still alive.
Sorta contradicts the
On Tue, 2 Dec 2014 08:28:22 -0500, Chris Mason wrote:
On Tue, Dec 2, 2014 at 7:39 AM, Miao Xie mi...@cn.fujitsu.com wrote:
This patchset implement the device scrub/replace function for RAID56, the
most implementation of the common data is similar to the other RAID type.
The differentia or
On Tue, Dec 2, 2014 at 10:30 PM, Zygo Blaxell
ce3g8...@umail.furryterror.org wrote:
IMHO if an optional filesystem feature has had a significant bug fixed
in the last six months, it probably shouldn't be enabled by default. ;)
Excellent point. I noted that my SuSE Tumbleweed enables extref by
On Tue, 2 Dec 2014 08:28:22 -0500, Chris Mason wrote:
On Tue, Dec 2, 2014 at 7:39 AM, Miao Xie mi...@cn.fujitsu.com wrote:
This patchset implement the device scrub/replace function for RAID56, the
most implementation of the common data is similar to the other RAID type.
The differentia or
On Tue, Dec 2, 2014 at 2:04 PM, Hugo Mills h...@carfax.org.uk wrote:
Is that correct: what btr sub list shows as top level is indeed the
parent subvolume?
No, it's the top-level subvolume. (See my earlier mail about
nomenclature). Parent subvolume has a number of meanings, none of
which
On Wed, Dec 3, 2014 at 2:43 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
Here's my approach to things:
Wow, thanks a lot people! I'm really benefiting from your experience here.
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
On Wed, Dec 3, 2014 at 5:41 AM, Satoru Takeuchi
takeuchi_sat...@jp.fujitsu.com wrote:
2. You delete /snap by snapper delete command by mistake.
Then snapper takes a pre snapshot just before deleting
/snap.
3. Now /snap is deleted, however, a pre snapshot which is
the same as /snap
Update on patch 4 and 6, other is not changed.
This nlink repair function is more generic than the original one.
The old one can only handle a specific case that the inode_ref is
invalid, either point to a non-exist parent inode or point to a invalid
inode(not dir or conflicting index/name).
The
Before this patch, when btrfsck found an error in root dir, it will only
output the following message root %llu root dir %llu error without any
detailed error.
Just add print_inode_error() to print out the whole error.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
cmds-check.c | 1 +
1
[BUG]
At least two users have already hit a bug in btrfs causing file
missing(Chromium config file).
The missing file's nlink is still 1 but its backref points to non-exist
parent inode.
This should be a kernel bug, but btrfsck fix is needed anyway.
[FIX]
For such nlink mismatch inode, we will
Add btrfs_unlink() and btrfs_add_link() functions in inode.c,
for the incoming btrfs_mkdir() and later inode operations functions.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Changlog:
v2:
Do dir name conflicting check before adding inode_backref or
dir_item/index.
v3:
Allow
Import lookup/del_inode_ref() function in inode-item.c, as base functions
for the incoming btrfs_add_link() and btrfs_unlink() functions.
Also modify btrfs_insert_inode_ref() and split_leaf() making them able
to deal with EXTENT_IREF incompat flag.
Signed-off-by: Qu Wenruo
With the previous btrfs inode operations patches, now we can use
btrfs_mkdir() to create the 'lost+found' dir to do some data salvage in
btrfsck.
This patch along with previous ones will make data salvage easier.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Changlog:
v2:
Fix a bug
Import btrfs_insert/del/lookup_extref() functions form kernel for the
incoming btrfs_add_link() and btrfs_unlink() functions.
As the base of incoming btrfs 'lost+found' recovery mechanism.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
ctree.h | 14
inode-item.c | 206
Hi,
I'd really like to see these patches included in btrfsck - they repaired my fs.
Once
Qu got them working they found additional corruptions. This time there was no
crash or stall
just an umount that left (chromium) files unlinked... The bug with these files
has been
hitting me for a
Hi,
(2014/12/03 14:03), Ed Tomlinson wrote:
Hi,
I'd really like to see these patches included in btrfsck - they repaired my fs.
Once
Qu got them working they found additional corruptions. This time there was no
crash or stall
just an umount that left (chromium) files unlinked... The bug
On Tue, Dec 02, 2014 at 06:07:30PM +, Filipe Manana wrote:
On chunk allocation error (label error_del_extent), after adding the
extent map to the tree and to the pending chunks list, we would leave
decrementing the extent map's refcount by 2 instead of 3 (our allocation
+ tree reference +
Original Message
Subject: Re: [PATCH 0/6] More generic inode nlink repair function
From: Satoru Takeuchi takeuchi_sat...@jp.fujitsu.com
To: Ed Tomlinson e...@aei.ca, linux-btrfs@vger.kernel.org
Date: 2014年12月03日 15:12
Hi,
(2014/12/03 14:03), Ed Tomlinson wrote:
Hi,
I'd
69 matches
Mail list logo
