On 2012.06.02 at 04:10 +0200, Markus Trippelsdorf wrote:
> I'm running the latest git kernel with the btrfs updates already merged.
> Today I've hit the following warnings during rsnapshot backup:
>
> Jun 1 22:26:30 x4 kernel: Adding 1953788k swap on /dev/sda2. Priority:-1
> extents:1 across:19
I'm running the latest git kernel with the btrfs updates already merged.
Today I've hit the following warnings during rsnapshot backup:
Jun 1 22:26:30 x4 kernel: Adding 1953788k swap on /dev/sda2. Priority:-1
extents:1 across:1953788k
Jun 2 01:52:30 x4 kernel: [ cut here ]
Hello,
here is the sixth iteration of my patches to improve filesystem freezing.
The change since last iteration is that filesystem can be frozen with open but
unlinked files. After some thinking, I've decided that the best way to handle
this is to block removal inside ->evict_inode() of each
We convert btrfs_file_aio_write() to use new freeze check. We also add proper
freeze protection to btrfs_page_mkwrite(). We also add freeze protection to
the transaction mechanism to avoid starting transactions on frozen filesystem.
At minimum this is necessary to stop iput() of unlinked file to c
When mnt_want_write() starts to handle freezing it will get a full lock
semantics requiring proper lock ordering. So push mnt_want_write() call
consistently outside of i_mutex.
CC: Chris Mason
CC: linux-btrfs@vger.kernel.org
Signed-off-by: Jan Kara
---
fs/btrfs/ioctl.c | 23 +++---
Seems it does not work.
What should be a next step in data recovering?
On 05/30/2012 10:50 PM, Gareth Pye wrote:
Stopping an experimental fsck for an exterimental file system would
probably be the worst idea possible. I'd only think about stopping it
after it had spent many many hours not doing
I made a little bit of progress recovering this mess, seems
btrfs-progs has improved since I last tried.
# ./btrfs-find-root /dev/mapper/tr5ut-vicep--library
[..]
Well block 317865713664 seems great, but generation doesn't match, have=574372,
want=575931
Well block 317874491392 seems great, but
If a transaction commit fails we don't abort it so we don't set an error on
the file system. This patch fixes that by actually calling the abort stuff
and then adding a check for a fs error in the transaction start stuff to
make sure it is caught properly. Thanks,
Signed-off-by: Josef Bacik
---
So we're forcing the eb's to have their ref count set to 1 so invalidatepage
works but this breaks lots of things, for example root nodes, and is just
plain wrong, we don't need to just evict all of this stuff. Also drop the
invalidatepage altogether and add a page_cache_release(). With this patc
I was getting hung on umount when a transaction was aborted because a range
of one of the free space inodes was still locked. This is because the nocow
stuff doesn't unlock anything on error. This fixed the problem and I
verified that is what was happening. Thanks,
Signed-off-by: Josef Bacik
-
I was getting lots of hung tasks and a NULL pointer dereference because we
are not cleaning up the transaction properly when it aborts. First we need
to reset the running_transaction to NULL so we don't get a bad dereference
for any start_transaction callers after this. Also we cannot rely on
wai
The transaction abort stuff was throwing warnings from the list debugging
code because we do a list_del_init outside of the delayed_refs spin lock.
The delayed refs locking makes baby Jesus cry so it's not hard to get wrong,
but we need to take the ref head mutex to make sure it's not being process
While doing my enospc work I got a transaction abortion that resulted in a
panic when we tried to unlock_page() an already unlocked page. This is
because we aren't calling extent_clear_unlock_delalloc with the locked page
so it was unlocking all the pages in the range. This is wrong since
__exten
In doing my enospc work I would sometimes error out in btrfs_save_ino_cache
which would abort the transaction but we'd still end up with a corrupted
file system. This is because we don't actually check the return value and
so if somethign goes wrong we just exit out and screw everything up. This
This is my reworked series of transaction abort fixes. The only ones that have
changed since yesterday are patches 5 and 6. Now we use the fs_state flag to
tell if our transaction aborted and we make sure to actually call the
transaction abort stuff if we have a commit error so the error gets set
Hi everyone,
My for-linus branch is updated for 3.5:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
This includes a fairly large change from Josef around data writeback
completion. Before, the writeback wasn't completed until the metadata
insertions for the extent
On Fri, Jun 01, 2012 at 09:41:46AM +0800, Miao Xie wrote:
> On Thu, 31 May 2012 10:31:48 -0400, Josef Bacik wrote:
> > On Thu, May 31, 2012 at 06:28:31PM +0800, Miao Xie wrote:
> >> Now if we remove the device that is specified when mounting, btrfs will
> >> update
> >> the mount information in /p
On Fri, Jun 01, 2012 at 09:22:53AM +0800, Liu Bo wrote:
> On 06/01/2012 04:04 AM, Josef Bacik wrote:
>
> > If we abort a transaction during the commit phase we can have people who
> > start new transactions because we nave no way of signaling to them that
> > something went wrong. So add a trans_
Hallo, Randall,
Du meintest am 01.06.12:
> I'm having a problem with a newly extended btrfs volume. It is
> running on debian testing with an almost stock 3.1.0 kernel with a
> little bit of patches
You should use a newer kernel, p.e. 3.3.7 or 3.4
Viele Gruesse!
Helmut
--
To unsubscribe from t
I'm having a problem with a newly extended btrfs volume. It is
running on debian testing with an almost stock 3.1.0 kernel with a
little bit of patches to get it compiling for my LaCie Network Space
v2 'Classic' (http://lacie.nas-central.org/wiki/Category:Network_Space_2).
It's been working perfe
20 matches
Mail list logo
