Re: GSoC-2016

[Christos Zoulas]

On Jun 10, 11:44pm, hrishi.go...@gmail.com (HRISHIKESH GOYAL) wrote:
-- Subject: Re: GSoC-2016

| Hello sir,
| 
| I am working on Htree directory index  traversing in lookup() operation. I
| am facing difficulty in testing of  Htree index code. I see the control
| never goes to Htree index traversal code because the value
| (i_flag&EXT4_INDEX) is false in the Ext4 disk image created by Htree
| indexing for directory enabled Linux's Ext4fs driver.
| Since index follows the link list indexing within a block I created 800
| files to make sure that it gets overflow the 4 kb block and Htree gets
| created. I m not able to figure out why directory index is still link list
| type. Or if it is not then why (i_flag&EXT4_INDEX) value is false.
| Regards
| Hrishikesh

The code that determines if the directory needs indexing is:
http://lxr.free-electrons.com/source/fs/ext4/dir.c?v=4.1#L39

It would be useful to run a linux kernel on another VM and put printfs
in the ext code to see when that function returns true...

Or you can keep creating more files :-) Eventually it will probably
decide to index if the other conditionals are true.

christos

| 
| On Sun, Jun 5, 2016 at 8:09 PM, Christos Zoulas  wrote:
| 
| > On Jun 5,  7:44am, hrishi.go...@gmail.com (HRISHIKESH GOYAL) wrote:
| > -- Subject: Re: GSoC-2016
| >
| > | Hello sir,
| > | I started doing Htree directory index, albeit some improvements in
| > | 'extents' are yet to be done. But those can be handled afterwards as I
| > have
| > | clear understanding of where and what is to be added/fixed. If you have
| > | some other plan for me then please let me know. I will do the job
| > | accordingly.
| > | Regards
| > | Hrishikesh
| >
| > No, I don't have any other plan. As you've seen I've committed the extents
| > changes (please take a look on my minor changes). Also we already got one
| > happy user who said in the mailing lists he was happy you implemented them.
| > As always please let me know if you need anything.
| >
| 
| Yes I have looked at the minor changes you made. I will follow NetBSD
| standard from now onwards.
| 
| 
| 
| >
| 
| Good luck,
| >
| > christos
| >
| 
| --001a113d65ca33c3610534f083ff
| Content-Type: text/html; charset=UTF-8
| Content-Transfer-Encoding: quoted-printable
| 
| Hello sir,
| I am working on Htree directory index=C2=A0 traversing in lo=
| okup() operation. I am facing difficulty in testing of=C2=A0 Htree index co=
| de. I see the control never goes to Htree index traversal code because the =
| value (i_flag&EXT4_INDEX) is false in the Ext4 disk image created by Ht=
| ree indexing for directory enabled Linux's Ext4fs driver.
| Since index follows the link list indexing within a block I created 800 fil=
| es to make sure that it gets overflow the 4 kb block and Htree gets created=
| . I m not able to figure out why directory index is still link list type. O=
| r if it is not then why (i_flag&EXT4_INDEX) value is false.
| Regards
| Hrishikesh
| On Sun, Jun 5, 2016 at 8:09 PM, Christos Zoulas chris...@zoulas.com> wrote:On Jun 5,=C2=A0 7=
| :44am, mailto:hrishi.go...@gmail.com"; target=3D"_blank">hrishi.g=
| o...@gmail.com (HRISHIKESH GOYAL) wrote:
| -- Subject: Re: GSoC-2016
| 
| | Hello sir,
| | I started doing Htree directory index, alb=
| eit some improvements in
| | 'extents' are yet to be done. But those can be handled afterwards=
|  as I have
| | clear understanding of where and what is to be added/fixed. If you have
| | some other plan for me then please let me know. I will do the job
| | accordingly.
| | Regards
| | Hrishikesh
| 
| No, I don't have any other plan. As you've seen I&#=
| 39;ve committed the extents
| changes (please take a look on my minor changes). Also we already got one
| happy user who said in the mailing lists he was happy you implemented them.=
| 
| As always please let me know if you need anything.Yes I have looked at the minor changes you made. I will follow=
|  NetBSD standard from now onwards.=C2=A0
| =C2=A0
| Good luck,
| 
| christos
| 
| 
| 
| --001a113d65ca33c3610534f083ff--
| 
| --MIMEStream=_0+101145_9380720988921_49487885396
| Content-Type: text/sanitizer-log; charset="iso-8859-1"
| Content-Transfer-Encoding: 8bit
| Content-Disposition: attachment; filename="sanitizer.log"
| 
| This message has been 'sanitized'.  This means that potentially
| dangerous content has been rewritten or removed.  The following
| log describes which actions were taken.
| 
| Sanitizer (start="1465582484"):
|   Forcing message to be multipart/mixed, to facilitate logging.
|   Writer (pos="3339"):
| Part (pos="3388"):
|   Part (pos="107"):
| SanitizeFile (filename="unnamed.txt", mimetype="text/plain"):
|   Match (names="unnamed.txt", rule="9"):
| Enforced policy: accept
| 
|   Part (pos="1780"):
| SanitizeFile (filename="unnamed.html, filetype.html", 
mimetype="text/html"):
|   Match (names="unnamed.html, filetype.

Re: GSoC-2016

[HRISHIKESH GOYAL]

Hello sir,

I am working on Htree directory index  traversing in lookup() operation. I
am facing difficulty in testing of  Htree index code. I see the control
never goes to Htree index traversal code because the value
(i_flag&EXT4_INDEX) is false in the Ext4 disk image created by Htree
indexing for directory enabled Linux's Ext4fs driver.
Since index follows the link list indexing within a block I created 800
files to make sure that it gets overflow the 4 kb block and Htree gets
created. I m not able to figure out why directory index is still link list
type. Or if it is not then why (i_flag&EXT4_INDEX) value is false.
Regards
Hrishikesh

On Sun, Jun 5, 2016 at 8:09 PM, Christos Zoulas  wrote:

> On Jun 5,  7:44am, hrishi.go...@gmail.com (HRISHIKESH GOYAL) wrote:
> -- Subject: Re: GSoC-2016
>
> | Hello sir,
> | I started doing Htree directory index, albeit some improvements in
> | 'extents' are yet to be done. But those can be handled afterwards as I
> have
> | clear understanding of where and what is to be added/fixed. If you have
> | some other plan for me then please let me know. I will do the job
> | accordingly.
> | Regards
> | Hrishikesh
>
> No, I don't have any other plan. As you've seen I've committed the extents
> changes (please take a look on my minor changes). Also we already got one
> happy user who said in the mailing lists he was happy you implemented them.
> As always please let me know if you need anything.
>

Yes I have looked at the minor changes you made. I will follow NetBSD
standard from now onwards.



>

Good luck,
>
> christos
>

Re: gets in the kernel

[David Holland]

On Wed, Jun 08, 2016 at 12:52:33PM +0200, Maxime Villard wrote:
 > Le 07/06/2016 ? 18:04, Christos Zoulas a ?crit :
 > >On Jun 7,  3:20pm, dholland-t...@netbsd.org (David Holland) wrote:
 > >-- Subject: Re: gets in the kernel
 > >
 > >| On Tue, Jun 07, 2016 at 12:36:54PM +0200, Maxime Villard wrote:
 > >|  > >I noticed that gets_s (a bounded version of gets) was added in the 
 > >kernel.
 > >|  > >While this iis nice, it conflicts with the c-11 "Annex K" which has a
 > >|  > >different prototype (takes rsize_t instead of size_t). Perhaps we 
 > >should
 > >|  > >rename this to kgets() or getl() now before it causes problems.
 > >|  >
 > >|  > This is not in the kernel, this is in the bootloader. So you can
 > >|  > forget kgets.  I don't think we need to rename it; it remains close
 > >|  > to what some people may be used to seeing, and does differ that
 > >|  > much.
 > >|
 > >| How about not giving people the false impression it's part of Annex K?
 > 
 > libsa is just made of many libc-like functions. getl and
 > bounded_gets are not close to anything in userland. gets_s is, even
 > though it is in annex K.

It's more important not to let anyone take away the false impression
that we're supporting annex K. Otherwise that could be a significant
impediment to getting it removed.

Anyway I'm not sure why you're so strenuously objecting to changing
the name; it's like you think we're criticizing you or something
rather than just polishing... :-/

I'm going to change it to gets2() unless anyone else has better ideas
soon.

-- 
David A. Holland
dholl...@netbsd.org

Re: Panic in tmpfs

[Paul Goyette]

On Fri, 10 Jun 2016, Michael Plass wrote:


On Jun 9, 2016, at 11:39 PM, Michael Plass wrote:


I have a fairly recent -current image that I can try this on. I'll do that.


OK, it looks like I was wrong, it is fixed with PR/50381. I couldn't make
the problem happen on the -current image (source date Wed May 18 11:28:44 2016 
+)


Great - thanks for checking!


+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

Re: Panic in tmpfs

[Michael Plass]

On Jun 9, 2016, at 11:39 PM, Michael Plass wrote:

> I have a fairly recent -current image that I can try this on. I'll do that.

OK, it looks like I was wrong, it is fixed with PR/50381. I couldn't make
the problem happen on the -current image (source date Wed May 18 11:28:44 2016 
+)

Thanks!
- Michael