On 28/11/13 08:16, Stan Hoeppner wrote:
Late reply. This one got lost in the flurry of activity...
On 11/22/2013 7:24 AM, David Brown wrote:
On 22/11/13 09:38, Stan Hoeppner wrote:
On 11/21/2013 3:07 AM, David Brown wrote:
For example, with 20 disks at 1 TB each, you can have:
...
It seems that the problem was that we didn't delete the corresponding
qgroup when deleting the subvolume, which was filling the metadata with
unused information. Removing all the stale qgroups fixes the problem and
allows subsequent subvolume creation without any quota disable/enable
action.
Jim Salter posted on Wed, 27 Nov 2013 15:09:18 -0500 as excerpted:
I can't find a manpage for the btrfs command that lists ANY information
about btrfs send, and I haven't found anything online about doing a size
check on send operations without actually sending the data. Anybody got
any help
Hi
I have a btrfs corruption on a external hard disk which cause mount to fail:
[179649.291047] btrfs: bdev /dev/loop0 errs: wr 2, rd 0, flush 0,
corrupt 0, gen 0
[179649.291473] parent transid verify failed on 59394068480 wanted
84587 found 84589
[179649.291763] parent transid verify failed on
On Tue, Nov 26, 2013 at 12:01:14PM +0100, Jan Engelhardt wrote:
While btrfs does its resizing, df stats are messed up.
Seen in linux-3.9.9. Don't know if it still occurs.
Bugreport moved to bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=66071),
I was not able to add you to CC though.
Subvolume deletion does not do a full transaction commit. This can lead
to an unexpected result when the system crashes between deletion and
commit, the subvolume directory will appear again. Add options to request
filesystem sync after each deleted subvolume or after the last one.
If the command
On Sun, Nov 17, 2013 at 07:16:18AM -0800, Marc MERLIN wrote:
On Mon, Nov 18, 2013 at 01:43:51AM +1100, Russell Coker wrote:
On Thu, 14 Nov 2013, Duncan 1i5t5.dun...@cox.net wrote:
It appears that running two scripts that create snapshots at the same
time as a script that removes maybe
On Thu, Nov 14, 2013 at 01:45:29AM +1100, Russell Coker wrote:
Nov 14 00:00:01 workstation /USR/SBIN/CRON[30993]: (root) CMD
(/usr/local/sbin/btrfs-make-snapshot minutes /home /var/log/snapshot.log)
Hello Anand,
I have sent a similar comment to your email thread in
http://www.spinics.net/lists/linux-btrfs/msg27547.html
I believe this approach of calculating freeable space is incorrect.
Try this:
- create a fresh btrfs
- create a regular file
- write some data into it in such a way, that it
On Sat, Nov 16, 2013 at 06:09:00PM +0100, Goffredo Baroncelli wrote:
the following patches implement the recursively snapshotting and
deleting of a subvolume.
Nice feature, but can we try to make the snapshot creation atomic? This
would need support from kernel of course.
I'm worried about
On Tue, Nov 19, 2013 at 01:36:43PM +0200, Emil Karlson wrote:
On Tue, Nov 19, 2013 at 1:00 PM, Pedro Fonseca pfons...@mpi-sws.org wrote:
Hi,
In another test, I've encountered a few situations that triggered a warning
message in record_one_backref(). I'm not sure if it's serious but it is
Hi David,
On 2013-11-28 19:31, David Sterba wrote:
On Sat, Nov 16, 2013 at 06:09:00PM +0100, Goffredo Baroncelli wrote:
the following patches implement the recursively snapshotting and
deleting of a subvolume.
Nice feature, but can we try to make the snapshot creation atomic? This
would
On Thu, 28 Nov 2013 17:59:07 +0100
David Sterba dste...@suse.cz wrote:
Subvolume deletion does not do a full transaction commit. This can lead
to an unexpected result when the system crashes between deletion and
commit, the subvolume directory will appear again. Add options to request
Hello everyone,
when I scrubbed one of my btrfs volumes today, the result of the scrub was:
total bytes scrubbed: 1.27TB with 2 errors
error details: super=2
corrected errors: 0, uncorrectable errors: 0, unverified errors: 0
and dmesg said:
btrfs: bdev /dev/mapper/tray errs: wr 0, rd 0, flush
Sebastian Ochmann posted on Thu, 28 Nov 2013 21:36:32 +0100 as excerpted:
when I scrubbed one of my btrfs volumes today, the result of the scrub
was:
total bytes scrubbed: 1.27TB with 2 errors error details: super=2
corrected errors: 0, uncorrectable errors: 0, unverified errors: 0
and
Hi Alex,
On 11/29/2013 01:39 AM, Alex Lyakas wrote:
Hello Anand,
I have sent a similar comment to your email thread in
http://www.spinics.net/lists/linux-btrfs/msg27547.html
I believe this approach of calculating freeable space is incorrect.
Try this:
- create a fresh btrfs
- create a regular
If so, i don't think this should be implemented in user space, Btrfs quota
implement such function in kernel space, but it also face a problem that
deleting a subvolume will break space accounting(because subvolume deletion
won't iterate the whole fs tree).
Hi Alex, Wang.
Thanks for
On 11/29/2013 03:36 AM, Roman Mamedov wrote:
On Thu, 28 Nov 2013 17:59:07 +0100
David Sterba dste...@suse.cz wrote:
Subvolume deletion does not do a full transaction commit. This can lead
to an unexpected result when the system crashes between deletion and
commit, the subvolume directory will
On thu, 28 Nov 2013 17:59:07 +0100, David Sterba wrote:
Subvolume deletion does not do a full transaction commit. This can lead
to an unexpected result when the system crashes between deletion and
commit, the subvolume directory will appear again. Add options to request
filesystem sync
Hi Alin,
On 11/28/2013 06:01 PM, Alin Dobre wrote:
It seems that the problem was that we didn't delete the corresponding
qgroup when deleting the subvolume, which was filling the metadata
with unused information. Removing all the stale qgroups fixes the
problem and allows subsequent subvolume
Hi,
On 11/29/2013 04:36 AM, Sebastian Ochmann wrote:
Hello everyone,
when I scrubbed one of my btrfs volumes today, the result of the scrub
was:
total bytes scrubbed: 1.27TB with 2 errors
error details: super=2
corrected errors: 0, uncorrectable errors: 0, unverified errors: 0
Here super
21 matches
Mail list logo
