Here is a simple scenario:
$ dd if=/dev/zero of=/mnt/btrfs/foobar bs=1k count=20;sync
$ btrfs fi df /mnt/btrfs
we get 20K used, but then
$ dd if=/dev/zero of=/mnt/btrfs/foobar bs=1k count=4 seek=4 conv=notrunc;sync
$ btrfs fi df /mnt/btrfs
we get 24K used.
Here is the problem, it is possible
On Thu, Apr 26, 2012 at 11:11 AM, Dave Chinner da...@fromorbit.com wrote:
writeback_inodes_sb(_nr) grabs s_umount lock when it want to start
writeback,
it may bring us deadlock problem when doing umount. So we introduce new
functions -- try_to_writeback_inodes_sb(_nr) -- which use
Hi Thomas,
there's a known regression in 3.3.0 that causes btrfs to report
out-of-space too early. If you upgrade to 3.3.3 or the latest 3.4 rc
the problem should be gone.
As for the two filesystems shown in btrfs fi show... I have no clue
what that is about. Did you maybe make a mistake to
Hello Bart,
there's a known regression in 3.3.0 that causes btrfs to report
out-of-space too early. If you upgrade to 3.3.3 or the latest 3.4 rc
the problem should be gone.
thanks for the information. I will update my kernel.
As for the two filesystems shown in btrfs fi show... I have no
On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer troh...@ennit.de wrote:
As for the two filesystems shown in btrfs fi show... I have no clue
what that is about. Did you maybe make a mistake to create a btrfs
filesystem on the whole disk at first?
That is possible. But afterwards I certainly
Well I think there is a btrfs superblock still present from the
full-disk filesystem. Due to the offset of the first partition from
the start of the disk, this superblock was not overwritten when you
created the filesystem inside the partition. But they very much
overlap and the full-disk
Hallo, Bart,
Du meintest am 26.04.12:
As for the two filesystems shown in btrfs fi show... I have no clue
what that is about. Did you maybe make a mistake to create a btrfs
filesystem on the whole disk at first?
That is possible. But afterwards I certainly repartioned the device
and
On Thu, Apr 26, 2012 at 10:58:04AM +0800, Miao Xie wrote:
The reason the deadlock is that:
TaskBtrfs-cleaner
umount()
down_write(s-s_umount)
sync_filesystem()
do auto-defragment and produce
On Thu, Apr 26, 2012 at 01:11:00PM +0200, Helmut Hullen wrote:
I now use to delete about the first 10 MByte of the target disk via dd
if=/dev/zero
FYI, the minimal amount of data you need to rewrite is 4k:
dd if=/dev/zero of=/dev/ice bs=1k count=4 seek=64
david
--
To unsubscribe from this
Hallo, David,
Du meintest am 26.04.12:
I now use to delete about the first 10 MByte of the target disk via
dd if=/dev/zero
FYI, the minimal amount of data you need to rewrite is 4k:
dd if=/dev/zero of=/dev/ice bs=1k count=4 seek=64
Thank you - I'll try to remember the next time I need
On Wed, Apr 25, 2012 at 11:40:14PM +0200, David Sterba wrote:
On Thu, Apr 26, 2012 at 12:04:51AM +0800, Daniel J Blueman wrote:
Correctly drop locks during error cases.
Signed-off-by: Daniel J Blueman dan...@quora.org
---
fyi, the same patch is already present in for-linus,
On Thu, Apr 26, 2012 at 03:55:52PM +0800, Xie Miao wrote:
On Thu, Apr 26, 2012 at 11:11 AM, Dave Chinner da...@fromorbit.com wrote:
writeback_inodes_sb(_nr) grabs s_umount lock when it want to start
writeback,
it may bring us deadlock problem when doing umount. So we introduce new
On Thu, Apr 26, 2012 at 02:39:23PM +0800, Liu Bo wrote:
Here is a simple scenario:
$ dd if=/dev/zero of=/mnt/btrfs/foobar bs=1k count=20;sync
$ btrfs fi df /mnt/btrfs
we get 20K used, but then
$ dd if=/dev/zero of=/mnt/btrfs/foobar bs=1k count=4 seek=4 conv=notrunc;sync
$ btrfs fi df
Hi BTRFS folks:
In my organization, many use cases exist for a time-based honoring
field for FS ACLs. I've done some brief research regarding this topic, but I
was unable to find any reference to such a thing in any file system.
I understand that a feature like time-based
On Thu, Apr 26, 2012 at 03:30:39PM -0400, David Bruzos wrote:
Hi BTRFS folks: In my organization, many use cases exist for a
time-based honoring field for FS ACLs. I've done some brief research
regarding this topic, but I was unable to find any reference to such a
thing in any file system.
Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted:
Hallo, Bart,
Du meintest am 26.04.12:
As for the two filesystems shown in btrfs fi show... I have no clue
what that is about. Did you maybe make a mistake to create a btrfs
filesystem on the whole disk at first?
Hi Chris:
Thank you for your very informative response. I will post the message
to linux-fsdevel and see what they have to say about it.
Any comments you would like to share regarding why something like what
I suggested has apparently never been implemented?
Again, thanks!
On 04/27/2012 01:14 AM, Chris Mason wrote:
On Thu, Apr 26, 2012 at 02:39:23PM +0800, Liu Bo wrote:
Here is a simple scenario:
$ dd if=/dev/zero of=/mnt/btrfs/foobar bs=1k count=20;sync
$ btrfs fi df /mnt/btrfs
we get 20K used, but then
$ dd if=/dev/zero of=/mnt/btrfs/foobar bs=1k
In 3.4-rc4, I've come across worker list corruption while scrubbing,
leading to (in two separate cases) warning [1] and crashing [2]. The
connection with scrubbing is likely the increased rate of worker
threads starting and stopping.
In btrfs_stop_workers, access to worker-worker_list is done
On 04/17/2012 03:35 PM, Arne Jansen wrote:
On 13.04.2012 09:43, Liu Bo wrote:
On 04/13/2012 03:19 PM, Arne Jansen wrote:
might be out of memory. How much does this vm (?) have?
Can you try to reduce the constants in disk-io.c:2003-2005?
Thanks,
Arne
Seems not related
Chris,
I'm one of those few people with several hats on, and one of them is a
packager/distro builder. From that perspective, btrfs-progs is rather
awkward to work with at this time, because as a packager, we like to
work with the tarballs, not git.
And currently, the latest tarball out there is
21 matches
Mail list logo
