With discard flag in btrfs_device, we will only push trim request to the
devices support that.
Now we don't return EOPNOTSUPP to the caller, so we won't trigger BUG_ONs
in the walk_log_tree functions if we mount a drive without DISCARD
using -o discard, but it is still possible if we get errors
Hello,
I formatted my home partition with btrfs, not realising that the fsck
tool can't actually fix errors, as I have just discovered on your
wiki.
Had I knew this I would have not used it so early, this detail you
would think would make distributions wary to make it an option on the
livecd with
- Forwarded message from Nico Schottelius
nico-lkml-20110...@schottelius.org -
To: LKML linux-ker...@vger.kernel.org
Date: Thu, 23 Jun 2011 12:53:37 +0200
From: Nico Schottelius nico-lkml-20110...@schottelius.org
Subject: Mis-Design of Btrfs?
Good morning devs,
I'm wondering whether
Am Donnerstag, 23. Juni 2011 schrieb Josef Bacik:
On Thu, Jun 23, 2011 at 07:37:12PM +0200, Martin Steigerwald wrote:
Hi!
Short summary: I suspect that rsync´ing files to a newly created
BTRFS partition with a subvolume *and* enabled space_cache triggers
the error mentioned in the
On 06/24/2011 08:46 AM, Martin Steigerwald wrote:
Am Donnerstag, 23. Juni 2011 schrieb Josef Bacik:
On Thu, Jun 23, 2011 at 07:37:12PM +0200, Martin Steigerwald wrote:
Hi!
Short summary: I suspect that rsync´ing files to a newly created
BTRFS partition with a subvolume *and* enabled
On Fri, Jun 24, 2011 at 5:16 PM, Michael Stephenson
mickstephen...@googlemail.com wrote:
Hello,
I formatted my home partition with btrfs, not realising that the fsck
tool can't actually fix errors, as I have just discovered on your
wiki.
Had I knew this I would have not used it so early, this
On Thu, Jun 23, 2011 at 11:59:32PM +0200, Jesper Juhl wrote:
It was pointed out by 'make versioncheck' that some includes of
linux/version.h were not needed in fs/ (fs/btrfs/ctree.h and
fs/omfs/file.c).
This patch removes them.
Signed-off-by: Jesper Juhl j...@chaosbits.net
Thanks, omfs
On 24 June 2011 14:46, Fajar A. Nugraha l...@fajar.net wrote:
On Fri, Jun 24, 2011 at 5:16 PM, Michael Stephenson
mickstephen...@googlemail.com wrote:
Hello,
I formatted my home partition with btrfs, not realising that the fsck
tool can't actually fix errors, as I have just discovered on your
well here is what I,m doing:
patch -p1 disk-io.patch
output: patching file fs/btrfs/disk-io.c
rmmod btrfs
rmmod lzo_compress
make -j3
make -j3 modules
make -j3 modules_install
cp arch/x86_64/boot/bzImage /boot/linux-next
depmod -a
(reboot)
modprobe btrfs
btrfs device scan
btrfs filesystem
On Thu, Jun 23, 2011 at 03:54:26PM -0400, Josef Bacik wrote:
A user reported this bug again where we have more bitmaps than we are supposed
to. This is because we failed to load the free space cache, but don't update
the ctl-total_bitmaps counter when we remove entries from the tree. This
A user reported this bug again where we have more bitmaps than we are supposed
to. This is because we failed to load the free space cache, but don't update
the ctl-total_bitmaps counter when we remove entries from the tree. This patch
fixes this problem and we should be good to go again.
Excerpts from David Sterba's message of 2011-06-24 11:58:20 -0400:
On Thu, Jun 23, 2011 at 03:54:26PM -0400, Josef Bacik wrote:
A user reported this bug again where we have more bitmaps than we are
supposed
to. This is because we failed to load the free space cache, but don't
update
Reject zero sized reads as soon as we know our I/O length, and don't
borther with locks or allocations that might have to be cleaned up
otherwise.
Signed-off-by: Christoph Hellwig h...@lst.de
Index: linux-2.6/fs/direct-io.c
===
---
i_alloc_sem has always been a bit of an odd lock. It's the only remaining
rw_semaphore that can be released by a different thread than the one that
locked it, and it's use case in the core direct I/O code is more like a
counter given that the writers already have external serialization.
This
i_alloc_sem is a rather special rw_semaphore. It's the last one that may
be released by a non-owner, and it's write side is always mirrored by
real exclusion. It's intended use it to wait for all pending direct I/O
requests to finish before starting a truncate.
Replace it with a hand-grown
Let filesystems handle waiting for direct I/O requests themselves instead
of doing it beforehand. This means filesystem-specific locks to prevent
new dio referenes from appearing can be held. This is important to allow
generalizing i_dio_count to non-DIO_LOCKING filesystems.
Signed-off-by:
Maintain i_dio_count for all filesystems, not just those using DIO_LOCKING.
This these filesystems to also protect truncate against direct I/O requests
by using common code. Right now the only non-DIO_LOCKING filesystem that
appears to do so is XFS, which uses an opencoded variant of the
For filesystems that delay their end_io processing we should keep our
i_dio_count until the the processing is done. Enable this by moving
the inode_dio_done call to the end_io handler if one exist. Note that
the actual move to the workqueue for ext4 and XFS is not done in
this patch yet, but
From: Jan Kara j...@suse.cz
Rewrite ext4_page_mkwrite() to use __block_page_mkwrite() helper. This
removes the need of using i_alloc_sem to avoid races with truncate which
seems to be the wrong locking order according to lock ordering documented in
mm/rmap.c. Also calling ext4_da_write_begin()
Add a new rw_semaphore to protect bmap against truncate. Previous
i_alloc_sem was abused for this, but it's going away in this series.
Note that we can't simply use i_mutex, given that the swapon code
calls -bmap under it.
Signed-off-by: Christoph Hellwig h...@lst.de
Index:
This scheme is much simpler, and saves the space of a spinlock_t and a
struct list_head in struct inode (typically 160 bytes on a non-debug 64-bit
system).
And I still haven't fixed that typo, damn. Updated in local version now
to make sure it won't be missed next time.
--
To unsubscribe
21 matches
Mail list logo
