Hi,
I btrfs file system created with one device /dev/sdb and mounted under
/btrfs1.
created one file /btrfs1/errno.h, one directory /btrfs1/dir1 and
2 subvolumes /btrfs1/subvol1 and /btrfs/subvol2
create directories and files under subvolume /btrfs1/subvol1.
Nothing inside /btrfs1/subvol2.
Bel
On 2015-04-22 07:19, sri wrote:
Hi,
I btrfs file system created with one device /dev/sdb and mounted under
/btrfs1.
created one file /btrfs1/errno.h, one directory /btrfs1/dir1 and
2 subvolumes /btrfs1/subvol1 and /btrfs/subvol2
create directories and files under subvolume /btrfs1/subvol1.
Noth
On Tue, Apr 21, 2015 at 10:26:23AM +0800, 王旭 wrote:
> > On 4/20/15 12:33 AM, xuw2...@gmail.com wrote:
> >> From: George Wang
>
> >> This means the value "_IOW*" will be negative when we store it in the int
> >> variables. Such as the "BTRFS_IOC_QGROUP_CREATE", it will be "0x4010942e"
> >> on
> >
On 04/13/2015 09:52 PM, Chris Mason wrote:
Large filesystems with lots of block groups can suffer long stalls during
commit while we create and send down all of the block group caches. The
more blocks groups dirtied in a transaction, the longer these stalls can be.
Some workloads average 10 seco
On Fri, Apr 17, 2015 at 02:02:15PM -0400, Josef Bacik wrote:
> We have this check in the kernel but not in userspace, which makes fsck fail
> when we wouldn't have a problem in the kernel. This was meant to catch this
> case because it really isn't good, unfortunately it will require a design
> c
Hi,
for incremental backups it would be useful to know the files that changed
between two snapshots. I found a paper about such a tool[1] that adds the
"btrfs subvolue diff" command, but it's not yet implemented in btrfs-tools in
Debian Jessie.
Is it in Git? Or somewhere else?
[1] https://www
On Tue, Apr 21, 2015 at 03:12:03PM +0800, Anand Jain wrote:
> From: Anand Jain
>
> Signed-off-by: Anand Jain
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kerne
On Tue, Apr 21, 2015 at 11:38:47PM -0400, Zygo Blaxell wrote:
> The BTRFS_IOC_RESIZE ioctl returns 0 on success, negative for POSIX
> errors, and positive for btrfs-specific errors.
>
> If resize fails with a btrfs-specific error, decode the error and
> report it. If we can't decode the error, re
On Wed, 22 Apr 2015 18:09:18 +0200, Lutz Vieweg wrote:
> On 04/13/2015 09:52 PM, Chris Mason wrote:
>> Large filesystems with lots of block groups can suffer long stalls during
>> commit while we create and send down all of the block group caches. The
>> more blocks groups dirtied in a transactio
On Tue, Apr 21, 2015 at 01:48:24AM -0400, Dan Merillat wrote:
> As long as the inode is intact, the file metadata can be restored.
> Directory data is restored at the end of search_dir. Errors are
> checked and returned, unless ignore_errors is requested.
>
> Signed-off-by: Dan Merillat
Applied
On 04/22/2015 12:37 PM, Holger Hoffstätte wrote:
> On Wed, 22 Apr 2015 18:09:18 +0200, Lutz Vieweg wrote:
>
>> On 04/13/2015 09:52 PM, Chris Mason wrote:
>>> Large filesystems with lots of block groups can suffer long stalls during
>>> commit while we create and send down all of the block group ca
On Tue, Apr 21, 2015 at 01:48:40AM -0400, Dan Merillat wrote:
> Symlinks and hardlinks are beyond the scope of these changes, I'll look
> into them if this looks good to everyone.
That would be appreciated. I'll send you a POC code to dump the
symlinks, it's missing the actual file creation and co
On Sun, Apr 19, 2015 at 02:46:28PM +0300, Lauri Võsandi wrote:
> This patch forces btrfs receive to issue chroot before
> parsing the btrfs stream using command-line flag -C
> to confine the process and minimize damage that could
> be done via malicious btrfs stream.
>
> Signed-off-by: Lauri Võsan
In 2012, I setup a Centos 6.x machine with a btrfs file system on top
of DRBD, we did some testing prior to going production and it seemed
fine, and has worked fine for a long time. However, now we are
encountering problems and was wondering if I could get any help.
[root@ysmha01 tmp]# btrfs fi sh
On Wed, Apr 22, 2015 at 05:47:17PM -0400, Diego Remolina wrote:
> In 2012, I setup a Centos 6.x machine with a btrfs file system on top
> of DRBD, we did some testing prior to going production and it seemed
> fine, and has worked fine for a long time. However, now we are
> encountering problems and
Current btrfs only support CRC32 checksum, and if csum_type is 1, we
will get 0 csum size, causing 0 division later destroy the whole kernel.
Or csum_type is later than 1, we will get data from other random memory
causing more problem.
So check csum_type in btrfs_check_super_valid() to avoid such
Although only RAID10 use sub_stripes, a hostile attack can modify chunk
tree and just add RAID10 bit to a single chunk.
Then btrfs_map_block will trigger a 0 division in kernel and destroy
everything.
Just add extra check when reading chunk from disk.
Reported-by: Lukas Lueg
Signed-off-by: Qu We
Thomas Koch posted on Wed, 22 Apr 2015 18:08:30 +0200 as excerpted:
> for incremental backups it would be useful to know the files that
> changed between two snapshots. I found a paper about such a tool[1] that
> adds the "btrfs subvolue diff" command, but it's not yet implemented in
> btrfs-tools
On Thu, Apr 23, 2015 at 03:43:35AM +, Duncan wrote:
> Thomas Koch posted on Wed, 22 Apr 2015 18:08:30 +0200 as excerpted:
>
> > for incremental backups it would be useful to know the files that
> > changed between two snapshots. I found a paper about such a tool[1] that
> > adds the "btrfs sub
I didn't check but "repair" should be made able to fix this situation
on an existing fs fairly easily by zeroing the BLOCK_GROUP_RAID10-bit
in case sub_stripes is zero or some unreasonable number and set the
bit in case sub_stripes has a reasonable, small value.
2015-04-23 5:00 GMT+02:00 Qu Wenruo
IMHO Zeroing the RAID10 bit is not a good idea to "repair".
As in that case, since the csum matched, normally we should trust
whatever we read. But if RAID10 bit is set but sub_stripe is still 0,
we are not sure whether the RAID10 bit or the sub_stripe value is wrong.
So what we know is, somethi
21 matches
Mail list logo
