On Wed, Aug 25, 2010 at 09:48:47PM -0400, Ted Ts'o wrote:
On Wed, Aug 25, 2010 at 05:30:42PM -0700, David Rientjes wrote:
We certainly hope that nobody will reimplement the same function without
the __deprecated warning, especially for order PAGE_ALLOC_COSTLY_ORDER
where there's no
On Wed, Aug 25, 2010 at 08:09:21PM -0700, David Rientjes wrote:
On Wed, 25 Aug 2010, Ted Ts'o wrote:
I think it's really sad that the caller can't know what the upper bounds
of its memory requirement are ahead of time or at least be able to
implement a memory freeing function when
On Wed, 2010-08-25 at 20:09 -0700, David Rientjes wrote:
Oh, we can determine an upper bound. You might just not like it.
Actually ext3/ext4 shouldn't be as bad as XFS, which Dave estimated to
be around 400k for a transaction. My guess is that the worst case for
ext3/ext4 is probably
Hi, I'm aware that btrfs doesn't have a functioning fsck tool that
fixes errors.
I was just wondering (I'm sure many are, also) if there is a working
btrfsck somewhere in the pipeline.
If there is some sort of rough estimate to when it'll be available,
please state it here.
If you're not
Le 25 août 2010 à 18:57, Johannes Hirte a écrit:
the other big question is:
Is btrfs with 2.6.36 really rockstable and ready to use in productive
environments?
I don't think so. There is at least one checksum bug and ENOSPC problems are
also still present.
I am planning to put 2
Hi,
I've just got this BUG: message in dmesg which I think is btrfs related.
I have a btrfs filesystem in a memory card which I use to contain the
cache and config of chromium (to avoid writing to much in the SSD):
/dev/mmcblk0p1 on /home/mafra/mmc type btrfs
On Wed, 18 Aug 2010 20:57:43 -0400, Chris Mason wrote:
Since the files are empty, and we aren't doing enough files to trigger
IO, it is really benchmarking the cost of the btree insertions/removals
in comparison with ext4. I do expect this to be higher because btrfs is
indexing the directories
On Thu, Aug 26, 2010 at 11:53:57AM +0200, Carlos R. Mafra wrote:
Hi,
I've just got this BUG: message in dmesg which I think is btrfs related.
I have a btrfs filesystem in a memory card which I use to contain the
cache and config of chromium (to avoid writing to much in the SSD):
On Do 26.Aug'10 at 7:53:36 -0400, Chris Mason wrote:
On Thu, Aug 26, 2010 at 11:53:57AM +0200, Carlos R. Mafra wrote:
Hi,
I've just got this BUG: message in dmesg which I think is btrfs related.
I have a btrfs filesystem in a memory card which I use to contain the
cache and config
On Saturday 14 August 2010 00:11:55 Andreas Philipp wrote:
On 12.08.2010 10:04, Yan, Zheng wrote:
On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp
philipp.andr...@gmail.com wrote:
Hi,
I am using a btrfs filesystem created with raid0 for data and metadata
for (temporary) storage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26.08.2010 15:27, Johannes Hirte wrote:
On Saturday 14 August 2010 00:11:55 Andreas Philipp wrote:
On 12.08.2010 10:04, Yan, Zheng wrote:
On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp
philipp.andr...@gmail.com wrote:
Hi,
I am using a
On Wed, 25 Aug 2010, David Rientjes wrote:
Because we can remove the flag, remove branches from the page allocator
slowpath, and none of these allocations actually are dependent on
__GFP_NOFAIL since they are all under PAGE_ALLOC_COSTLY_ORDER.
Then we can simply remove __GFP_NOFAIL? Functions
On Thursday 26 August 2010 15:39:25 Andreas Philipp wrote:
On 26.08.2010 15:27, Johannes Hirte wrote:
Looks like another manifestation of the csum bug. Are you able to read all
files from the affected volume? Did you tried a balance with an 2.6.34
kernel
after the test with 2.6.35?
Johannes Hirte, Thu, 26 Aug 2010 18:38:30 +0200:
On Thursday 26 August 2010 15:39:25 Andreas Philipp wrote:
On 26.08.2010 15:27, Johannes Hirte wrote:
Looks like another manifestation of the csum bug. Are you able to
read all files from the affected volume? Did you tried a balance with
an
On Thu, 26 Aug 2010, Christoph Lameter wrote:
Because we can remove the flag, remove branches from the page allocator
slowpath, and none of these allocations actually are dependent on
__GFP_NOFAIL since they are all under PAGE_ALLOC_COSTLY_ORDER.
Then we can simply remove __GFP_NOFAIL?
On Thu, Aug 26, 2010 at 03:43:52AM -0500, Chester wrote:
Hi, I'm aware that btrfs doesn't have a functioning fsck tool that
fixes errors.
I was just wondering (I'm sure many are, also) if there is a working
btrfsck somewhere in the pipeline.
If there is some sort of rough estimate to when
Thanks chris, and that's wonderful!
Lemme just hope silent corruption won't kill me by then (I had to
force my computer to turn off a couple of times (but that was so long
ago))
Looking forward to the releases.
On Thu, Aug 26, 2010 at 7:57 PM, Chris Mason chris.ma...@oracle.com wrote:
On Thu,
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index e112902..271ca89 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -497,7 +497,7 @@ static void print_one_uuid(struct btrfs_fs_devices
*fs_devices)
devs_found++;
}
if (devs_found total) {
- printf(\t***
18 matches
Mail list logo
