I was hitting weird issues when trying to remove hole extents and it turned out
it was because I was sending non-aligned offsets down to
btrfs_lookup_csums_range. So add an assert for this in case somebody trips over
this in the future. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
I'm playing with acl permission on btrfs (my favourite filesytem).
When I set ACL permission on directory happens that this permission doesn't
propagate inside the directory structure.
As you can see from the following example after the second level the ACL's
rules are completely forgotten.
On Tue, Oct 08, 2013 at 11:41:39AM +0800, Anand Jain wrote:
for mounted btrfs filesystem this patch proposes to add
mount point and group profile to the filesystem show output.
this helps user to quickly understand short details of the
btrfs filesystem quickly.
end user using this new btrfs
On Tue, Oct 15, 2013 at 4:56 PM, Giuseppe Fierro giuse...@fierro.org wrote:
I'm playing with acl permission on btrfs (my favourite filesytem).
When I set ACL permission on directory happens that this permission doesn't
propagate inside the directory structure.
As you can see from the
When a directory has a default ACL and a subdirectory is created
under that directory, btrfs_init_acl() is called when the
subdirectory's inode is created to initialize the inode's ACL
(inherited from the parent directory) but it was clearing the ACL
from the inode after setting it if
On Tue, Oct 15, 2013 at 06:44:00PM +0100, Filipe David Borba Manana wrote:
When a directory has a default ACL and a subdirectory is created
under that directory, btrfs_init_acl() is called when the
subdirectory's inode is created to initialize the inode's ACL
(inherited from the parent
On Tue, Oct 15, 2013 at 7:00 PM, Josef Bacik jba...@fusionio.com wrote:
On Tue, Oct 15, 2013 at 06:44:00PM +0100, Filipe David Borba Manana wrote:
When a directory has a default ACL and a subdirectory is created
under that directory, btrfs_init_acl() is called when the
subdirectory's inode is
Due to an off-by-one error, it is possible to reproduce a bug
when the inode cache is used.
The same inode number is assigned twice, the second time this
leads to an EEXIST in btrfs_insert_empty_items().
The issue can happen when a file is removed right after a subvolume
is created and then a
On Tue, October 15, 2013 at 20:08 (+0200), Stefan Behrens wrote:
Due to an off-by-one error, it is possible to reproduce a bug
when the inode cache is used.
The same inode number is assigned twice, the second time this
leads to an EEXIST in btrfs_insert_empty_items().
The issue can happen
After changing the default subvolume, I can't mount a nested subvolume with a
correct relative pathname to the default subvolume; it can only be mounted by
absolute path or subvolid.
Setup:
3.11.4-302.fc20.x86_64
btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc20.x86_64
dir = a directory, sub=a
On Oct 15, 2013, at 1:23 PM, Chris Murphy li...@colorremedies.com wrote:
So should the mounting of relative pathnames still work?
Is it related to fix: [PATCH] Btrfs: use right root when checking for hash
collision
can't move subvols into subvols
I wrote:
On Oct 11, 2013, at 8:22 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote:
Hi,
Kernel 3.12-rc built from HEAD has the same issue as 3.10 and 3.11
Ok, I was able to fix my problem by booting from an old kernel
(3.8.7) and it allowed me to mount the fs.
Interesting.
It could
On Oct 15, 2013, at 1:23 PM, Chris Murphy li...@colorremedies.com wrote:
After changing the default subvolume, I can't mount a nested subvolume with a
correct relative pathname to the default subvolume; it can only be mounted by
absolute path or subvolid.
Setup:
3.11.4-302.fc20.x86_64
Probably a bit too obscure to turn this into an xfstest? At least nobody
complained so far, and this reproducer takes me 1m57 to run, so nothing I want
in each xfstest cycle.
I disagree. The entire point of regression tests is to trigger bugs
that the usual processes failed to find, like
On Oct 15, 2013, at 2:50 PM, David Sterba dste...@suse.cz wrote:
On Tue, Oct 15, 2013 at 01:23:44PM -0600, Chris Murphy wrote:
After changing the default subvolume, I can't mount a nested subvolume
with a correct relative pathname to the default subvolume; it can only
be mounted by absolute
On Tue, Oct 15, 2013 at 02:58:22PM -0600, Chris Murphy wrote:
Looks like this changed with the 3.2 kernel Subvolumes mountable by
full path, I thought that was in addition to relative rather than a
total change in behavior. Good to know.
Yes, the pre-3.2 behaviour was limited to subvolumes in
On Oct 15, 2013, at 3:48 PM, David Sterba dste...@suse.cz wrote:
On Tue, Oct 15, 2013 at 02:58:22PM -0600, Chris Murphy wrote:
Looks like this changed with the 3.2 kernel Subvolumes mountable by
full path, I thought that was in addition to relative rather than a
total change in behavior.
On Tue, Oct 15, 2013 at 07:02:47PM +0100, Filipe David Manana wrote:
Can you put this into an xfstest please? Thanks,
A new one or just add it to an existing one (and which)?
There's xfstests/shared/051 that tests ACLs, but is run only against xfs
and udf. I haven't verified it wrt btrfs,
preview as below..
Label: none uuid: 26d539a5-8968-4cf0-b4b5-5fd50105f8a0 mounted: /btrfs
Group profile: Metadata: single Metadata: DUP Data: single
It would look better if the profile types are grouped together,
As of now mkfs.btrfs and balance don't agree on the same set
of
On Tue, Oct 15, 2013 at 06:49:41PM +0200, David Sterba wrote:
On Sat, Oct 12, 2013 at 11:47:52PM +0800, Eryu Guan wrote:
I hit a segfault when deleting a subvolume with very long name(4096),
How do you get a valid pathname longer than PATH_MAX which is 4096 ?
Just as the steps in
20 matches
Mail list logo
