Re: test f_extent_htree fails on 1.44.3-rc1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 27, 2018 at 01:12:07PM -0400, Theodore Y. Ts'o wrote:
> On Wed, Jun 27, 2018 at 06:14:47PM +0200, Lukas Czerner wrote:
> > Meanwhile I've created something as well. I am not yet ready to send it
> > since I was going to review and create test for it. It has some more
> > functionality
> 
> Sorry, I should have sent out my path last night.
> 
> Thanks for taking as stab at it, but it's a lot of code changes when
> I'm trying to stablize things for a 1.44.3 release.  In fact, even if
> we weren't at 1.44.3-rc1, this level of new functionality is something
> that I'd want to save for 1.45.

Understandable. I didn't really like the idea of adding separate options
for that so I changed the -d parameter.

But you're right, it's a bit much for rc1. How about just changing the
test to skip if we find extended attributes on the source directory a
move this to after the 1.44.3 is release ?

> 
> I also wonder if we want to add this much flexibility/functionality,
> that perhaps we should push it to an external file, since the main
> people who would be using this are people who are building file
> sytsems for IOT devices.  So it would probably be something that might
> look like this:
> 
> [defaults]
> 	copy_xattrs = yes
> 	uid = 1000
> 	gid = 1000
> 
> [sources]
> 	root_dir = {
> 		pathname = test_appliance/etc
> 		copy_xattrs = no
> 		uid = 0
> 		gid = 0
> 	}
> 	application = {
> 		pathname = build
> 	}
> 
> [overrides]
> 	/usr/bin/sudo = {
> 		mode = 04755
> 		uid = 0
> 		uid = 0
> 		selinux_label = wizard_t
> 	}
> 
> ... and since I'm not the target user of such feature, I'd really want
> to recruit or consult with one of the people who had originally
> proposed the mke2fs -d feature to see what they think.

I'm not the target user either, but the -d options scheme I proposed
is not really in conflict with supporting external config file as well.

-Lukas

> 
> One advantage of using the above syntax is we can reuse the parsing
> code we already have in libsupport/profile.c, which we use for
> mke2fs.conf and e2fsck.conf.
> 
> Oh, and I might want to take a look at what's in contrib/e2fsdroid.c
> to see what other functionality the AOSP folks need/want, and see what
> if any of it makes sense for us to support officially upstream.
> 
> What do folks think?
> 
> 						- Ted



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux