-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/09/14 05:30, Zygo Blaxell wrote:
> On Wed, Sep 10, 2014 at 01:27:36PM +0100, Bob Williams wrote:
>> I have two 2TB disks formatted as a btrfs raid1 array, mirroring
>> both data and metadata. Last night I started
>>
>> # btrfs filesystem balance
The behaviour of a 'chattr -c' consists of getting the current flags,
clearing the FS_COMPR_FL bit and then sending the result to the set
flags ioctl - this means the bit FS_NOCOMP_FL isn't set in the flags
passed to the ioctl. This results in the compression property not being
cleared from the ino
Regression test for btrfs where removing the flag FS_COMPR_FL
(chattr -c) from an inode wouldn't clear its compression property.
This was fixed in the following linux kernel patch:
Btrfs: add missing compression property remove in btrfs_ioctl_setflags
Signed-off-by: Filipe Manana
---
tests/bt
On Thu, Sep 11, 2014 at 5:41 AM, Satoru Takeuchi
wrote:
> Hi Filipe,
>
> (2014/09/11 0:10), Filipe Manana wrote:
>> The behaviour of a 'chattr -c' consists of getting the current flags,
>> clearing the FS_COMPR_FL bit and then sending the result to the set
>> flags ioctl - this means the bit FS_NO
On 10/09/14 19:43, Goffredo Baroncelli wrote:
> On 09/10/2014 02:27 PM, Bob Williams wrote:
>> I have two 2TB disks formatted as a btrfs raid1 array, mirroring both
>> data and metadata. Last night I started
>>
>> # btrfs filesystem balance
>
>
> May be that I am missing something obvious, howev
Bob Williams posted on Thu, 11 Sep 2014 10:56:14 +0100 as excerpted:
> So if a RAID1/two disk system uses the disks symmetrically, why did my
> balance command take 22 hours? That's what puzzles me, as my
> understanding of RAID1 is that the disk use *is* symmetrical.
What you're missing is what
On 2014-09-11 02:40, Russell Coker wrote:
> On Mon, 8 Sep 2014, Austin S Hemmelgarn wrote:
>> Also, I've found out the hard way that system chunks really should be
>> RAID1, NOT RAID10, otherwise it's very likely that the filesystem
>> won't mount at all if you lose 2 disks.
>
> Why would that be
On Thu, Sep 11, 2014 at 07:19:00AM -0400, Austin S Hemmelgarn wrote:
> On 2014-09-11 02:40, Russell Coker wrote:
> > Also it would be nice if there was a N-way mirror option for system data.
> > As
> > such data is tiny (32MB on the 120G filesystem in my workstation) the space
> > used by havin
On 2014-09-11 07:38, Hugo Mills wrote:
> On Thu, Sep 11, 2014 at 07:19:00AM -0400, Austin S Hemmelgarn wrote:
>> On 2014-09-11 02:40, Russell Coker wrote:
>>> Also it would be nice if there was a N-way mirror option for system data.
>>> As
>>> such data is tiny (32MB on the 120G filesystem in my
On Thu, Sep 11, 2014 at 08:06:21AM -0400, Austin S Hemmelgarn wrote:
> On 2014-09-11 07:38, Hugo Mills wrote:
> > On Thu, Sep 11, 2014 at 07:19:00AM -0400, Austin S Hemmelgarn wrote:
> >> On 2014-09-11 02:40, Russell Coker wrote:
> >>> Also it would be nice if there was a N-way mirror option for sy
On 09/10/2014 04:55 PM, Samer Al-Kiswany wrote:
> Hi,
>
> Thank you for help.
>
> I am seeing a strange behavior when fsync()ing a directory.
>
> Here is what I do
>
> for (i=0; i < 100,000, i++){
> .
> mkdir(p/child_i)
> fsync(p)
> }
>
> Btrfs seems to achieve around 100k fs
On 09/09/2014 05:19 AM, rongqing...@windriver.com wrote:
> From: Li RongQing
>
> It is impossible that csum_size is larger than sizeof(long), but the codes
> still add the handler for this condition, like allocate new memory, for
> extension. If it becomes true someday, copying csum_size size mem
On 09/05/2014 06:58 PM, beh...@converseincode.com wrote:
> From: VinÃcius Tinti
>
> Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
> compliant equivalent. This is the original VLAIS struct.
>
> struct {
> struct shash_desc shash;
> char ctx[crypto_shash_de
After a disk died and was replaced, "btrfs device delete missing" is
taking more than 10 days on an otherwise idle server:
# btrfs fi show /home
Label: none uuid: 84d087aa-3a32-46da-844f-a233237cf04f
Total devices 3 FS bytes used 362.44GiB
devid2 size 1.71TiB used 365.03GiB
Label: 'Root' uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
Total devices 2 FS bytes used 7.46GiB
devid1 size 9.31GiB used 8.06GiB path /dev/sdh6
devid3 size 9.31GiB used 8.06GiB path
/dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa
# ls -al /dev/disk/by-uuid
On 09/03/2014 09:35 AM, Miao Xie wrote:
> There were several problems about chunk mutex usage:
> - Lock chunk mutex when updating metadata. It would cause the nested
> deadlock because updating metadata might need allocate new chunks
> that need acquire chunk mutex. We remove chunk mutex at t
Hi Liu,
>> I've recently run into a deadlock on 3.15.10, don't know if the kernel
>> stack-trace is useful: http://pastebin.com/guQNDAMX
>
> FYI, this's been fixed by https://patchwork.kernel.org/patch/4727711/
Thanks for letting me know.
- Clemens
--
To unsubscribe from this list: send the line
Mark Murawski posted on Thu, 11 Sep 2014 10:45:58 -0400 as excerpted:
> Label: 'Root' uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
> Total devices 2 FS bytes used 7.46GiB
> devid1 size 9.31GiB used 8.06GiB path /dev/sdh6
> devid3 size 9.31GiB used 8.06GiB path
> /
When a ranged fsync finishes if there are still extent maps in the modified
list, still set the inode's logged_trans and last_log_commit. This is important
in case an inode is fsync'ed and unlinked in the same transaction, to ensure its
inode ref gets deleted from the log and the respective dentrie
Tomasz Chmielewski posted on Thu, 11 Sep 2014 17:22:15 +0200 as excerpted:
> After a disk died and was replaced, "btrfs device delete missing" is
> taking more than 10 days on an otherwise idle server:
>
> # btrfs fi show /home
> Label: none uuid: 84d087aa-3a32-46da-844f-a233237cf04f
>
On Sep 11, 2014, at 1:31 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> I wouldn't try defragging now, but it might be worthwhile to stop the
> device delete (rebooting to do so since I don't think there's a cancel)
'btrfs replace cancel' does exist, although I haven't tried it.
Something isn't r
On 09/11/14 09:34, Chris Mason wrote:
On 09/05/2014 06:58 PM, beh...@converseincode.com wrote:
From: VinÃcius Tinti
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This is the original VLAIS struct.
struct {
struct shash_desc shash;
After a disk died and was replaced, "btrfs device delete missing" is
taking more than 10 days on an otherwise idle server:
Something isn't right though, because it's clearly neither reading nor
writing at \
anywhere close to 1/2 the drive read throughput. I'm curious what
'iotop -d30 -o' \
sho
Chris Murphy posted on Thu, 11 Sep 2014 15:25:51 -0600 as excerpted:
> On Sep 11, 2014, at 1:31 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>>
>> I wouldn't try defragging now, but it might be worthwhile to stop the
>> device delete (rebooting to do so since I don't think there's a cancel)
>
> 'btr
For btrfs fi show, -d|--all-devices & -m|--mounted will
overwrite each other, so if specified both, let the user
know that he should not use them at the same time.
Signed-off-by: Gui Hecheng
---
changelog:
v1->v2: add option conflict descriptions to manpage and usage.
---
Documentation/b
Do you means we can handle it like below? I think it is not better,
if that, csum size can not the expand, and the code in csum_tree_block
seems redundancy;
If you do not want to truncate in first patch, I think we can try to avoid it
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 22a367
On Sep 11, 2014, at 5:51 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Thu, 11 Sep 2014 15:25:51 -0600 as excerpted:
>
>> On Sep 11, 2014, at 1:31 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>>>
>>> I wouldn't try defragging now, but it might be worthwhile to stop the
>>> devic
It would be nice if a file system mounted ro counted as ro snapshots for btrfs
send.
When a file system is so messed up it can't be mounted rw it should be regarded
as ro for all operations.
--
Sent from my Samsung Galaxy Note 2 with K-9 Mail.
--
To unsubscribe from this list: send the line "un
Russell Coker posted on Fri, 12 Sep 2014 15:19:04 +1000 as excerpted:
> It would be nice if a file system mounted ro counted as ro snapshots for
> btrfs send.
>
> When a file system is so messed up it can't be mounted rw it should be
> regarded as ro for all operations.
Indeed, and that has been
Chris Murphy posted on Thu, 11 Sep 2014 20:10:26 -0600 as excerpted:
> And then when I think about just creating a new fs, using btrfs
> send/receive, the snapshots need to be ro first.
FWIW, at this point I'd forget about send/receive and create the backup
(assuming one doesn't exist already) u
Hi Gui,
(2014/09/12 10:15), Gui Hecheng wrote:
> For btrfs fi show, -d|--all-devices & -m|--mounted will
> overwrite each other, so if specified both, let the user
> know that he should not use them at the same time.
>
> Signed-off-by: Gui Hecheng
> ---
> changelog:
> v1->v2: add option co
Chris Murphy posted on Thu, 11 Sep 2014 20:10:26 -0600 as excerpted:
> Sure. But what's the next step? Given 260+ snapshots might mean well
> more than 350GB of data, depending on how deduplicated the fs is, it
> still probably would be faster to rsync this to a pile of drives in
> linear/concat+X
On Sep 11, 2014, at 11:19 PM, Russell Coker wrote:
> It would be nice if a file system mounted ro counted as ro snapshots for
> btrfs send.
>
> When a file system is so messed up it can't be mounted rw it should be
> regarded as ro for all operations.
Yes it's come up before, and there's a q
33 matches
Mail list logo
