Changed the test 079 to be generic for all filesystems and to be
executed for all filesystems.
In src/t_immutable.c which is compiled for Linux only, replaced the
old style XFS and ext2 specific code for setting the append-only and
immutable flags by generic code that makes use of the
Use _scratch_mkfs / _scratch_mkfs_sized instead of _scratch_mkfs_xfs
where possible.
Execute 015, 062, 083, 117, 120 and 192 for all filesystems, these
tests used to be XFS specific.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
015 |5 +++--
062 |4 ++--
062.out |
Hi,
Running on kernel 3.0 without patches. Mount options for the btrfs
partition in question were `defaults, noatime, compress=lzo,
space_cache, autodefrag, inoce_cache'. Partition cannot be mounted
again with a 3.0 kernel after reboot. Partition can, however, be
mounted successfully with a
I'd like btrfs to support full featured send and receive in the future.
If nobody is currently working on it, I'll grab the send/receive lock.
Now that I own the lock, I'm opening several discussions on this topic.
If you are in a hurry, it would be great if you could at least read and
comment on
When we mount a btrfs filesystem from read-only media there will be no
read/write devices; for example mounting an SD card with its lock enabled.
This triggers an immediate BUG during mount:
kernel BUG at .../fs/btrfs/super.c:984!
This is triggered by statfs when calculating the free space in
Hello,
We've seen a lot of reports of people having these constant long pauses
when doing things like sync or such. The stack traces usually all look
the same, one is btrfs-transaction stuck in btrfs_wait_marked_extents
and one is btrfs-submit-# stuck in get_request_wait. I had originally
On 08/01/2011 09:38 AM, Andy Whitcroft wrote:
When we mount a btrfs filesystem from read-only media there will be no
read/write devices; for example mounting an SD card with its lock enabled.
This triggers an immediate BUG during mount:
kernel BUG at .../fs/btrfs/super.c:984!
This is
Excerpts from Josef Bacik's message of 2011-08-01 11:21:34 -0400:
Hello,
We've seen a lot of reports of people having these constant long pauses
when doing things like sync or such. The stack traces usually all look
the same, one is btrfs-transaction stuck in btrfs_wait_marked_extents
and
On 08/01/2011 11:45 AM, Chris Mason wrote:
Excerpts from Josef Bacik's message of 2011-08-01 11:21:34 -0400:
Hello,
We've seen a lot of reports of people having these constant long pauses
when doing things like sync or such. The stack traces usually all look
the same, one is
We always look for delalloc bytes in our io_tree so we can fill in delalloc.
This is fine in most cases, but if we're writing out the btree_inode this is
just a superfluous tree search on the io_tree, and if we have a lot of metadata
dirty this could be an expensive check. So instead check to see
Hello:
Sorry if this has been asked before, but I haven't found any related
information. This fails:
1. create an snapshot.
2. mark it as the default.
3. remove the snapshot.
4. umount the volume and mount it again.
My question is, shouldn't it mount the top level path as a fall back if
Excerpts from Josef Bacik's message of 2011-08-01 12:03:34 -0400:
On 08/01/2011 11:45 AM, Chris Mason wrote:
Excerpts from Josef Bacik's message of 2011-08-01 11:21:34 -0400:
Hello,
We've seen a lot of reports of people having these constant long pauses
when doing things like sync or
On 08/01/2011 01:54 PM, Chris Mason wrote:
Excerpts from Josef Bacik's message of 2011-08-01 12:03:34 -0400:
On 08/01/2011 11:45 AM, Chris Mason wrote:
Excerpts from Josef Bacik's message of 2011-08-01 11:21:34 -0400:
Hello,
We've seen a lot of reports of people having these constant long
Excerpts from Josef Bacik's message of 2011-08-01 14:01:35 -0400:
On 08/01/2011 01:54 PM, Chris Mason wrote:
Excerpts from Josef Bacik's message of 2011-08-01 12:03:34 -0400:
On 08/01/2011 11:45 AM, Chris Mason wrote:
Excerpts from Josef Bacik's message of 2011-08-01 11:21:34 -0400:
When doing a writepage we call writepages to try and write out any other dirty
pages in the area. This could cause problems where we commit a transaction and
then have somebody else dirtying metadata in the area as we could end up writing
out a lot more than we care about, which could cause
Hi Jan
On 08/01/2011 02:22 PM, Jan Schmidt wrote:
I furthermore realized that the term subvolume is omitted in favor
of the term snapshot. This is because I tend to think of snapshots
being read-only (though I very much appreciate they are not). Just
replace the term wherever you feel
On Thu, Jul 28, 2011 at 04:28:04PM -0400, Chris Mason wrote:
The slow performance is probably coming from reading in the metadata
associated with the snapshot extents. The new readahead extentions from
Arne should help once we've adapted them to it. The easiest way to make
sure is to hit
On Mon, Aug 1, 2011 at 4:26 PM, Bruce Guenter br...@untroubled.org wrote:
On Thu, Jul 28, 2011 at 04:28:04PM -0400, Chris Mason wrote:
The slow performance is probably coming from reading in the metadata
associated with the snapshot extents. The new readahead extentions from
Arne should help
On Mon, Aug 01, 2011 at 04:41:10PM -0600, cwillu wrote:
The keystroke should be alt-sysrq-w.
Right. What I meant is that no backtraces are showing up. I was
actually using
echo w /proc/sysrq-trigger
and all I was seeing is:
SysRq : Show Blocked State
task
On Mon, Aug 1, 2011 at 12:21 PM, Chris Mason chris.ma...@oracle.com wrote:
Excerpts from Josef Bacik's message of 2011-08-01 14:01:35 -0400:
On 08/01/2011 01:54 PM, Chris Mason wrote:
Excerpts from Josef Bacik's message of 2011-08-01 12:03:34 -0400:
On 08/01/2011 11:45 AM, Chris Mason wrote:
Excerpts from cwillu's message of 2011-08-01 19:28:35 -0400:
On Mon, Aug 1, 2011 at 12:21 PM, Chris Mason chris.ma...@oracle.com wrote:
Excerpts from Josef Bacik's message of 2011-08-01 14:01:35 -0400:
On 08/01/2011 01:54 PM, Chris Mason wrote:
Excerpts from Josef Bacik's message of
Excerpts from Bruce Guenter's message of 2011-08-01 18:59:15 -0400:
On Mon, Aug 01, 2011 at 04:41:10PM -0600, cwillu wrote:
The keystroke should be alt-sysrq-w.
Right. What I meant is that no backtraces are showing up. I was
actually using
echo w /proc/sysrq-trigger
and all I
On 08/02/2011 12:11 AM, Josef Bacik wrote:
We always look for delalloc bytes in our io_tree so we can fill in delalloc.
This is fine in most cases, but if we're writing out the btree_inode this is
just a superfluous tree search on the io_tree, and if we have a lot of
metadata
dirty this
On 08/02/2011 09:32 AM, liubo wrote:
On 08/02/2011 12:11 AM, Josef Bacik wrote:
We always look for delalloc bytes in our io_tree so we can fill in delalloc.
This is fine in most cases, but if we're writing out the btree_inode this is
just a superfluous tree search on the io_tree, and if we
When balancing, we'll first try to shrink devices for some space,
but if it is working on a full multi-disk partition with raid protection,
we may encounter a bug, that is, while shrinking, total_bytes may be less
than bytes_used, and btrfs may allocate a dev extent that accesses out of
device's
25 matches
Mail list logo
