On Mon, May 17, 2010 at 08:30:32PM -0400, Chris Mason wrote:
> On Tue, May 18, 2010 at 02:14:05AM +0200, Jakob Unterwurzacher wrote:
> > On 17/05/10 21:36, Chris Mason wrote:
> > >
> > > That should be a zero second window, we try to force things to disk
> > > during renames.
> > >
> > > Could yo
when used Posix File System Test Suite(pjd-fstest) to test btrfs,
some cases about setfacl failed when noacl mount option used.
I simplified used commands in pjd-fstest, and the following steps
can reproduce it.
# cd btrfs-part/
# mkdir aaa
# setfacl -m m::rw aaa<- su
On btrfs, do the following
--
# su user1
# cd btrfs-part/
# touch aaa
# getfacl aaa
# file: aaa
# owner: user1
# group: user1
user::rw-
group::rw-
other::r--
# su user2
# cd btrfs-part/
# setfacl -m u::rwx aaa
# getfacl aaa
# file: aaa
# owner: user1
# group: user1
On Tue, May 18, 2010 at 02:14:05AM +0200, Jakob Unterwurzacher wrote:
> On 17/05/10 21:36, Chris Mason wrote:
> >
> > That should be a zero second window, we try to force things to disk
> > during renames.
> >
> > Could you please try this patch:
> >
> > diff --git a/fs/btrfs/ordered-data.c b/fs
On 17/05/10 21:36, Chris Mason wrote:
>
> That should be a zero second window, we try to force things to disk
> during renames.
>
> Could you please try this patch:
>
> diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
> index c9f1020..9370a71 100644
> --- a/fs/btrfs/ordered-data.c
On 17/05/10 22:09, Chris Mason wrote:
>>> -rw-r--r-- 1 root root 20 2010-05-17 17:06:25.812016407 +0200 01280.cur
>>> -rw-r--r-- 1 root root 20 2010-05-17 17:06:25.835999490 +0200 01281.cur
>>> -rw-r--r-- 1 root root 0 2010-05-17 17:06:25.868035485 +0200 01282.cur
>>> [...]
>>> -rw-r--r-- 1 root r
On Mon, May 17, 2010 at 03:25:54PM -0400, Josef Bacik wrote:
> On Mon, May 17, 2010 at 08:04:21PM +0200, Jakob Unterwurzacher wrote:
> > Hi!
> >
> > Following Ubuntu's dpkg+ext4 problems I wanted to see if btrfs would
> > solve them all. And it nearly does! Now I wonder if the remaining 0.2
> > se
On Mon, May 17, 2010 at 08:04:21PM +0200, Jakob Unterwurzacher wrote:
> Hi!
>
> Following Ubuntu's dpkg+ext4 problems I wanted to see if btrfs would
> solve them all. And it nearly does! Now I wonder if the remaining 0.2
> seconds window of exposing 0-size files could be closed too.
That should b
On Mon, May 17, 2010 at 08:04:21PM +0200, Jakob Unterwurzacher wrote:
> Hi!
>
> Following Ubuntu's dpkg+ext4 problems I wanted to see if btrfs would
> solve them all. And it nearly does! Now I wonder if the remaining 0.2
> seconds window of exposing 0-size files could be closed too.
>
> I tested
On 05/17/2010 02:04 PM, Jakob Unterwurzacher wrote:
Hi!
Following Ubuntu's dpkg+ext4 problems I wanted to see if btrfs would
solve them all. And it nearly does! Now I wonder if the remaining 0.2
seconds window of exposing 0-size files could be closed too.
Nearly does not seem that reassuri
Hi!
Following Ubuntu's dpkg+ext4 problems I wanted to see if btrfs would
solve them all. And it nearly does! Now I wonder if the remaining 0.2
seconds window of exposing 0-size files could be closed too.
I tested using two simple scripts (attached for reference) on kernel
2.6.34-rc7:
- rentest cr
If btrfs_ioctl_snap_destroy() deletes a snapshot but finishes
with end_transaction(), the cleaner kthread may come in and
drop the root in the same transaction. If that's the case, the
root's refs still == 1 in the tree when btrfs_del_root() deletes
the item, because commit_fs_roots() hasn't updat
On Monday 17 May 2010 08:26:00 Sean Bartell wrote:
> What hasn't been tested:
> - Multiple real-world filesystems (I only have one)
> - 8192-byte blocks (ReiserFS crashes horribly on mount)
Well, AFAIK 8192 blocks are supported only on platforms that have 8kb memory
pages (e.g. Alpha), it's a bug
13 matches
Mail list logo
