On Fri, Nov 4, 2011 at 1:39 PM, Christoph Hellwig h...@infradead.org wrote:
On Fri, Nov 04, 2011 at 10:38:04AM +0800, Eryu Guan wrote:
btrfs requires at least 256M file system size, so check 'fssize' in
_scratch_mkfs_sized first and give it a proper value. Otherwise
mkfs.btrfs will complain
On 11/4/2011 7:06 AM, Eryu Guan wrote:
On Fri, Nov 4, 2011 at 1:39 PM, Christoph Hellwig h...@infradead.org wrote:
On Fri, Nov 04, 2011 at 10:38:04AM +0800, Eryu Guan wrote:
btrfs requires at least 256M file system size, so check 'fssize' in
_scratch_mkfs_sized first and give it a proper
On 11/4/2011 1:09 AM, Liu Bo wrote:
Btrfs has an expensive commit transaction, if we commit a transaction every
time we fsync,
the performance is not that good. Instead of this, we introduce a write-ahead
log to make
our fsync faster.
So if you do fsync for your data, it means your data is
We all keep getting those stupid warnings from use_block_rsv when running
stress.sh, and it's because the delayed insertion stuff is being stupid. It's
not the delayed insertion stuffs fault, it's all just stupid. When marking an
inode dirty for oh say updating the time on it, we just do a
Hello!
I read Chris was supposed to demonstrate btrfsck on LinuxCon[0]. Does
anybody knows if that ever happen?
Also, does btrfsck development moved to the new GIT repository, or is
it still not released?
I'm holding to my broken btrfs partition[0] for more than a year now :-/
Thanks.
[1]
On Fri, Nov 04, 2011 at 05:18:54PM -0400, Josef Bacik wrote:
V1-V2: I stupidly thought I could get away with some flushing if we needed
space but I was wrong, we could deadlock, so add a btrfs_add_bytes_noflush
variant that will not do any flushing and will just return ENOSPC which will
let
