Hi
I have a non-rootfs btrfs partition that I use for some work where I
like to keep some snapshots. The partition is about 160GB big and has
about 80-90 GB of data.
I often see the following errors:
Apr 29 20:41:24 DesktopMB kernel: [47030.195270] INFO: task sync:2450
blocked for more than 120
On Sat, 12 Apr 2014 10:15:25 Chris Murphy wrote:
I'm already aware that SELinux's automatic labelling of files is not
aware of subvolumes[*].
[*] https://wiki.debian.org/SELinux/Setup#btrfs
I'm not sure exactly what it means since there is always a subvolume (ID 5),
and I don't
[keeping dropped CC although not customary on this list]
Am Mittwoch, 30. April 2014, 00:42:44 schrieb Duncan:
Holger Hoffstätte posted on Tue, 29 Apr 2014 17:33:09 + as excerpted:
On Tue, Apr 29, 2014 at 05:10:31PM +, Duncan wrote:
David Sterba posted on Tue, 29 Apr 2014 17:56:47
I David
thanks, to take care of these enhancements.
On 04/29/2014 09:23 PM, Mike Fleetwood wrote:
On 29 April 2014 17:02, David Sterba dste...@suse.cz wrote:
The entire device size may not be available to the filesystem, eg. if
it's modified via resize. Print this information if it can be
On Tue, Apr 29, 2014 at 08:23:08PM +0100, Mike Fleetwood wrote:
/dev/sda7, ID: 3
Device size:10.00GiB
FS occuppied:5.00GiB
Spelling mistake. s/occuppied/occupied/.
+void print_device_sizes(int fd, struct device_info *devinfo, int mode)
+{
+
On Wed, Apr 30, 2014 at 01:39:27PM +0200, Goffredo Baroncelli wrote:
Sample:
/dev/sda7, ID: 3
Device size:10.00GiB
FS occuppied:5.00GiB
Spelling mistake. s/occuppied/occupied/.
I found a bit unclear the FS occupied terms.
We're running out of terms
Hi,
While trying to view the btrfs-check manpage today (using
integration-20140429), I noticed that the current symlink overwrites
the actual btrfs-check manpage, making an unusable, cyclic link:
$ man btrfs-check
man: can't resolve /usr/share/man/man8/btrfs-check.8.gz: Too many
levels
On Tue, Apr 29, 2014 at 08:14:30PM +0100, Mike Fleetwood wrote:
On 29 April 2014 16:56, David Sterba dste...@suse.cz wrote:
Changes:
* btrfs filesystem disk_usage - renamed to usage
* added a section of overall filesystem usage, that used to be in the
'fi df' output
* btrfs device
On Wed, Apr 30, 2014 at 10:15:11AM +0200, Martin Steigerwald wrote:
[keeping dropped CC although not customary on this list]
Am Mittwoch, 30. April 2014, 00:42:44 schrieb Duncan:
* btrfs filesystem disk_usage - renamed to usage
[On the CLI, usage is often used to print a briefer
On Tue, Apr 29, 2014 at 05:10:31PM +, Duncan wrote:
To users familiar with Unix/POSIX/Linux CLI, usage (as --usage) is most
often seen as a rather less common and generally briefer form of --help,
usually with the distinction being that --help may be a screen or more of
output, while
On 30/04/14 13:11, David Sterba wrote:
On Wed, Apr 30, 2014 at 01:39:27PM +0200, Goffredo Baroncelli wrote:
Sample:
/dev/sda7, ID: 3
Device size:10.00GiB
FS occuppied:5.00GiB
Spelling mistake. s/occuppied/occupied/.
I found a bit unclear the FS occupied
On Wed, 30 Apr 2014, Frank Kingswood wrote:
On 30/04/14 13:11, David Sterba wrote:
On Wed, Apr 30, 2014 at 01:39:27PM +0200, Goffredo Baroncelli wrote:
I found a bit unclear the FS occupied terms.
We're running out of terms to describe and distinguish the space that
the filesystem uses.
On Apr 29, 2014, at 1:21 PM, Juan Orti Alcaine juan.o...@miceliux.com wrote:
Hello, I noticed that file capabilites are lost on received subvolumes, so I
opened the bug report #68891 [1]. I don't know if other xattrs are affected
by
this problem.
I can reproduce the reported problem with
On Apr 30, 2014, at 2:01 AM, Russell Coker russ...@coker.com.au wrote:
On Sat, 12 Apr 2014 10:15:25 Chris Murphy wrote:
I'm already aware that SELinux's automatic labelling of files is not
aware of subvolumes[*].
[*] https://wiki.debian.org/SELinux/Setup#btrfs
I'm not sure exactly what
David Sterba posted on Wed, 30 Apr 2014 15:01:34 +0200 as excerpted:
On Tue, Apr 29, 2014 at 05:10:31PM +, Duncan wrote:
To users familiar with Unix/POSIX/Linux CLI, usage (as --usage) is
most often seen as a rather less common and generally briefer form of
--help
I did a quick check
On 04/30/2014 03:37 PM, David Taylor wrote:
On Wed, 30 Apr 2014, Frank Kingswood wrote:
On 30/04/14 13:11, David Sterba wrote:
On Wed, Apr 30, 2014 at 01:39:27PM +0200, Goffredo Baroncelli wrote:
I found a bit unclear the FS occupied terms.
We're running out of terms to describe and
Hi,
a couple of months ago there has been some discussion about issues
when using btrfs on bcache:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/31018
From looking at the mailing list archives I cannot tell whether or not
this issue has been resolved in current kernels from either
On Mon, 28 Apr 2014 00:09:34 +0300
Niv Gal Waizer niv...@gmail.com wrote:
[this reply comes after we've dealt with the issue on IRC]
A week ago I installed kernel 3.14 on an existing laptop with btrfs
install by ubuntu. I upgraded ubuntu to 14.04 a few days ago.
I had problems installing a
On Fri, 28 Feb 2014 10:34:36 Roman Mamedov wrote:
I've a 18 tera hardware raid 5 (areca ARC-1170 w/ 8 3 gig drives) in
Do you sleep well at night knowing that if one disk fails, you end up with
basically a RAID0 of 7x3TB disks? And that if 2nd one encounters unreadable
sector during
On Sun, 2 Mar 2014 21:35:30 Chris Mason wrote:
On 03/02/2014 07:23 PM, Russell Coker wrote:
I've attached the kernel message log from a GPF that occurred running the
Debian kernel package of kernel 3.13.4. This happens repeatedly and
started doing so with Debian kernel 3.12.8.
This is
Is there a design/technical reason behind btrfs using checksums
separately per block, versus checksumming into a merkle tree?
Where I'm coming from: there's a Linux kernel device mapper module
called dm-verity, which let's you verify the contents of a block
device using a merkle tree (at mount
Hi,
I had 3 x 3 TB drives in an almost full btrfs raid1 setup containing
only large (~20 GB) files linearly written and not modified after.
Then one of the drives got busted. Mounting the fs in degraded mode
and adding a new fresh drive to rebuild raid1, generated several
...blocked for more than
Russell Coker posted on Thu, 01 May 2014 11:52:33 +1000 as excerpted:
I've just been doing some experiments with a failing disk used for
backups (so I'm not losing any real data here).
=:^)
The dup option for metadata means that the entire filesystem
structure is intact in spite of having
23 matches
Mail list logo
