From nobody@FreeBSD.org  Sun Jan 10 21:39:31 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 1BDDF106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 10 Jan 2010 21:39:31 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id E64548FC14
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 10 Jan 2010 21:39:30 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o0ALdUk8091092
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 10 Jan 2010 21:39:30 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o0ALdUCg091090;
	Sun, 10 Jan 2010 21:39:30 GMT
	(envelope-from nobody)
Message-Id: <201001102139.o0ALdUCg091090@www.freebsd.org>
Date: Sun, 10 Jan 2010 21:39:30 GMT
From: vermaden <vermaden@interia.pl>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ext2fs does not work on filesystems with really big directories
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         142597
>Category:       kern
>Synopsis:       [ext2fs] ext2fs does not work on filesystems with really big directories
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-fs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jan 10 21:40:01 UTC 2010
>Closed-Date:    Sat Jan 11 01:15:23 UTC 2014
>Last-Modified:  Sat Jan 11 01:15:23 UTC 2014
>Originator:     vermaden
>Release:        8.0-RELEASE
>Organization:
>Environment:
FreeBSD  8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009     root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386 
>Description:
Under Linux I created ext2fs filesystem with -I 128 option (inode size), used it on Linux for a while, now tried to mount and use it under FreeBSD, filesystem mounts, gives no errors on mount, but I cannot list or access contents of really big dorectories (with ls(1) for example), I am able to list/use smaller dirs on that filesystem for example.

Should not be a chipset support problem, because other disk works without a problem on this Intel Q35 chipset without any problems/timeouts.

Maybe its because these non default features of ext2 enabled on the Linux side:
- dir_index
- large_file

Regards,
vermaden
>How-To-Repeat:
# mount -t ext2fs /dev/ada1s1 /mnt/GREEN
# cd /mnt/GREEN
# ls small_dir
(contents ...)
# ls big_dir
(no output)

.. and dmesg(8) shows two lines (always two lines for single ls command on big directory:
g_vfs_done():ada1s1[READ(offset=-711084466176, length=4096)]error = 5
g_vfs_done():ada1s1[READ(offset=-711084466176, length=4096)]error = 5

~ % tune2fs -l /dev/ada1s1
tune2fs 1.41.8 (11-Jul-2009)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d8e5e867-db65-499b-b158-1887bf718e45
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284000
Reserved block count:     0
Free blocks:              232569649
Free inodes:              91511889
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   256
Filesystem created:       Fri Dec 18 19:34:50 2009
Last mount time:          Sat Jan  9 15:18:02 2010
Last write time:          Sat Jan  9 15:43:23 2010
Mount count:              0
Maximum mount count:      27
Last checked:             Sat Jan  9 15:18:02 2010
Check interval:           15552000 (6 months)
Next check after:         Thu Jul  8 16:18:02 2010
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group wheel)
First inode:              11
Inode size:               128
Default directory hash:   half_md4
Directory Hash Seed:      e48cf467-623f-4625-99c8-19c028a27620
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-fs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sun Jan 10 21:43:16 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=142597 

From: Aditya Sarawgi <sarawgi.aditya@gmail.com>
To: bug-followup@FreeBSD.org, vermaden@interia.pl
Cc:  
Subject: Re: kern/142597: [ext2fs] ext2fs does not work on filesystems with
 really big directories
Date: Mon, 25 Jan 2010 21:54:54 +0000

 Hi,
 
 Can you give a rough estimate of the number of files you have in the 
 directory, and if possible at what value is this breaking. The current 
 code supports large_file and I don't think dir_index maybe causing this, 
 the only thing dir_index would do is make the lookup faster. The other 
 thing I would like to know is that when you do ls big_dir do you get the 
 prompt back or ls keeps waiting.
 
 
 Thanks
 Aditya Sarawgi

Date: 26 Jan 2010 08:46:15 +0100
From: vermaden <vermaden@interia.pl>
Sender: vermaden@interia.pl
To: Aditya Sarawgi <sarawgi.aditya@gmail.com>
Subject: =?UTF-8?q?Re:_kern/142597:_[ext2fs]_ext2fs_does_not_work_on_filesystems_with_really_big_directories?=

 Hi Aditya,
 
 About delay/hanging the ls(1) command on too big directories,
 it ends right away without displaying no results, like that:
 
 % ls big_dir
 % (this prompt shows instantly)
 
 I have put a lot of data about that filesystem here (sizes/counts):
 http://strony.toya.net.pl/~vermaden/tmp/ext2fs_file_dir_count_size.tar.gz
 
 Here is the described behaviour:
 
 / # mount -t ext2fs /dev/ada1s1 /mnt/ext2fs
 / # cd /mnt/ext2fs
 /mnt/ext2fs # ls
 done___download/ done___storage/ done___vermaden/ f1/ lost+found/
 /mnt/ext2fs # ls f1
 2009/                                                              complete=
 /
 F1 Jerez 1997.mp4                                                  current/
 GP2 2009 - 09 ITALY - RACE 1.wmv                                   links/
 ROC.2008.Race.Of.Champions.London.WS.EurosportHD.XviD.English.avi  samples/
 /mnt/ext2fs # ls done___vermaden
 /mnt/ext2fs # ls done___storage
 8.0-RELEASE-i386-memstick.img.gz                 [E3] Californication/
 Compaq_CQ60.xp.rar                               audiobook/
 Desktop/                                         bluetooth.USB/
 Duchy moich bylych 2009.avi                      burn/
 Duchy moich bylych 2009.txt                      cd/
 FIFA 98/                                         date_format.reg
 Galerianki (2009) PL.avi                         franz/
 OOo_3.1.0_FreeBSD80Intel_install_en-US.tbz       iso/
 OOo_3.1.0_FreeBSD80Intel_langpack_en-US.tar.bz2  lista.html
 PuzzleDB.tar.gz                                  mis/
 PuzzlePack.rar                                   movie/
 Stan gry 2009.avi                                pendrive/
 Stan gry 2009.txt                                swf/
 [E1] Californication/                            vbox_xp.vdi.gz
 [E2] Californication/
 /mnt/ext2fs # ls done___download
 /mnt/ext2fs # cd done___download
 /mnt/ext2fs/done___download # ls
 /mnt/ext2fs/done___download # ls -a
 /mnt/ext2fs/done___download #=20
 
 Unfortunelly, I do not know the exact count/size of the directory, to make =
 it not listing.
 
 ----------------------------------------------------------------------
 Ten dzien jest raz w roku!
 Nie przegap go i wygraj prezenty >> http://link.interia.pl/f2594

From: "Pedro F. Giffuni" <giffunip@tutopia.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/142597: [ext2fs] ext2fs does not work on filesystems with really big directories
Date: Thu, 4 Feb 2010 10:33:16 -0800 (PST)

 --0-388987257-1265308396=:19947
 Content-Type: text/plain; charset=us-ascii
 
 A bug was recently found in UFS that may be related:
 
 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+current/freebsd-fs
 
 I made a similar patch for the BSD-licensed ext2fs and,
 while here, I fixed some typos that were also cleaned
 from UFS.
 
 
       
 --0-388987257-1265308396=:19947
 Content-Type: application/octet-stream; name="patch-ext2_alloc.c"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename="patch-ext2_alloc.c"
 
 LS0tIC4uL2V4dDJmcy5ic2QvZXh0Ml9hbGxvYy5jCTIwMTAtMDEtMTcgMTk6
 MDA6NDcuMDAwMDAwMDAwICswMDAwCisrKyBleHQyX2FsbG9jLmMJMjAxMC0w
 Mi0wNCAxMzoyMDoxNC4wMDAwMDAwMDAgKzAwMDAKQEAgLTYwLDcgKzYwLDcg
 QEAKIHN0YXRpYyBkYWRkcl90CWV4dDJfbm9kZWFsbG9jY2coc3RydWN0IGlu
 b2RlICosIGludCwgZGFkZHJfdCwgaW50KTsKIHN0YXRpYyBkYWRkcl90ICBl
 eHQyX21hcHNlYXJjaChzdHJ1Y3QgbV9leHQyZnMgKiwgY2hhciAqLCBkYWRk
 cl90KTsKIC8qCi0gKiBBbGxvY2F0ZSBhIGJsb2NrIGluIHRoZSBmaWxlIHN5
 c3RlbS4KKyAqIEFsbG9jYXRlIGEgYmxvY2sgaW4gdGhlIGZpbGVzeXN0ZW0u
 CiAgKgogICogQSBwcmVmZXJlbmNlIG1heSBiZSBvcHRpb25hbGx5IHNwZWNp
 ZmllZC4gSWYgYSBwcmVmZXJlbmNlIGlzIGdpdmVuCiAgKiB0aGUgZm9sbG93
 aW5nIGhpZXJhcmNoeSBpcyB1c2VkIHRvIGFsbG9jYXRlIGEgYmxvY2s6CkBA
 IC0xMzcsOCArMTM3LDggQEAKICAgICAgICAgfQogbm9zcGFjZToKIAlFWFQy
 X1VOTE9DSyh1bXApOwotCWV4dDJfZnNlcnIoZnMsIGNyZWQtPmNyX3VpZCwg
 ImZpbGUgc3lzdGVtIGZ1bGwiKTsKLQl1cHJpbnRmKCJcbiVzOiB3cml0ZSBm
 YWlsZWQsIGZpbGUgc3lzdGVtIGlzIGZ1bGxcbiIsIGZzLT5lMmZzX2ZzbW50
 KTsKKwlleHQyX2ZzZXJyKGZzLCBjcmVkLT5jcl91aWQsICJmaWxlc3lzdGVt
 IGZ1bGwiKTsKKwl1cHJpbnRmKCJcbiVzOiB3cml0ZSBmYWlsZWQsIGZpbGVz
 eXN0ZW0gaXMgZnVsbFxuIiwgZnMtPmUyZnNfZnNtbnQpOwogCXJldHVybiAo
 RU5PU1BDKTsKIH0KIApAQCAtMzMyLDcgKzMzMiw3IEBACiB9CiAKIC8qCi0g
 KiBBbGxvY2F0ZSBhbiBpbm9kZSBpbiB0aGUgZmlsZSBzeXN0ZW0uCisgKiBB
 bGxvY2F0ZSBhbiBpbm9kZSBpbiB0aGUgZmlsZXN5c3RlbS4KICAqIAogICov
 CiBpbnQKQEAgLTc5MCw3ICs3OTAsNyBAQAogCX0KIAlFWFQyX1VOTE9DSyh1
 bXApOwogCWJkd3JpdGUoYnApOwotCXJldHVybiAoY2cgKiBmcy0+ZTJmcy0+
 ZTJmc19pcGcgKyBpcHJlZiArMSk7CisJcmV0dXJuICgodW5zaWduZWQgaW50
 KWNnICogZnMtPmUyZnMtPmUyZnNfaXBnICsgaXByZWYgKzEpOwogfQogCiAv
 KgpAQCAtOTQyLDcgKzk0Miw3IEBACiB9CiAKIC8qCi0gKiBGc2VyciBwcmlu
 dHMgdGhlIG5hbWUgb2YgYSBmaWxlIHN5c3RlbSB3aXRoIGFuIGVycm9yIGRp
 YWdub3N0aWMuCisgKiBGc2VyciBwcmludHMgdGhlIG5hbWUgb2YgYSBmaWxl
 c3lzdGVtIHdpdGggYW4gZXJyb3IgZGlhZ25vc3RpYy4KICAqIAogICogVGhl
 IGZvcm0gb2YgdGhlIGVycm9yIG1lc3NhZ2UgaXM6CiAgKglmczogZXJyb3Ig
 bWVzc2FnZQo=
 
 --0-388987257-1265308396=:19947--

From: "Pedro F. Giffuni" <giffunip@tutopia.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/142597: [ext2fs] ext2fs does not work on filesystems with really big directories
Date: Wed, 10 Feb 2010 18:56:28 -0800 (PST)

 --0-1240140841-1265856988=:21423
 Content-Type: text/plain; charset=us-ascii
 
 The previous patch was incomplete.
 
 There is now a complete fix for UFS available as
 SVN Revision 203763.
 Translating it to ext2fs gives the attached patch.
 (I kept the file system --> filesystem corrections)
 
 Please note that ext2_blkpref is very different to
 ffs1_blkpref. We probably have to review that function
 for (un)signed issues too.
 
 
 
       
 --0-1240140841-1265856988=:21423
 Content-Type: application/octet-stream; name="patch-ext2_alloc.c"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename="patch-ext2_alloc.c"
 
 LS0tIC4uL2V4dDJmcy5ic2QvZXh0Ml9hbGxvYy5jCTIwMTAtMDEtMTcgMTk6
 MDA6NDcuMDAwMDAwMDAwICswMDAwCisrKyBleHQyX2FsbG9jLmMJMjAxMC0w
 Mi0xMCAyMTo0MDoyNS4wMDAwMDAwMDAgKzAwMDAKQEAgLTUxLDE2ICs1MSwx
 NiBAQAogI2luY2x1ZGUgPGZzL2V4dDJmcy9mcy5oPgogI2luY2x1ZGUgPGZz
 L2V4dDJmcy9leHQyX2V4dGVybi5oPgogCi1zdGF0aWMgZGFkZHJfdAlleHQy
 X2FsbG9jY2coc3RydWN0IGlub2RlICosIGludCwgZGFkZHJfdCwgaW50KTsK
 K3N0YXRpYyBkYWRkcl90CWV4dDJfYWxsb2NjZyhzdHJ1Y3QgaW5vZGUgKiwg
 dV9pbnQsIGRhZGRyX3QsIGludCk7CiBzdGF0aWMgdV9sb25nCWV4dDJfZGly
 cHJlZihzdHJ1Y3QgaW5vZGUgKik7CiBzdGF0aWMgdm9pZAlleHQyX2ZzZXJy
 KHN0cnVjdCBtX2V4dDJmcyAqLCB1aWRfdCwgY2hhciAqKTsKIHN0YXRpYyB1
 X2xvbmcJZXh0Ml9oYXNoYWxsb2Moc3RydWN0IGlub2RlICosIGludCwgbG9u
 ZywgaW50LAotCQkJCWRhZGRyX3QgKCopKHN0cnVjdCBpbm9kZSAqLCBpbnQs
 IGRhZGRyX3QsIAorCQkJCWRhZGRyX3QgKCopKHN0cnVjdCBpbm9kZSAqLCB1
 X2ludCwgZGFkZHJfdCwgCiAJCQkJCQlpbnQpKTsKLXN0YXRpYyBkYWRkcl90
 CWV4dDJfbm9kZWFsbG9jY2coc3RydWN0IGlub2RlICosIGludCwgZGFkZHJf
 dCwgaW50KTsKK3N0YXRpYyBkYWRkcl90CWV4dDJfbm9kZWFsbG9jY2coc3Ry
 dWN0IGlub2RlICosIHVfaW50LCBkYWRkcl90LCBpbnQpOwogc3RhdGljIGRh
 ZGRyX3QgIGV4dDJfbWFwc2VhcmNoKHN0cnVjdCBtX2V4dDJmcyAqLCBjaGFy
 ICosIGRhZGRyX3QpOwogLyoKLSAqIEFsbG9jYXRlIGEgYmxvY2sgaW4gdGhl
 IGZpbGUgc3lzdGVtLgorICogQWxsb2NhdGUgYSBibG9jayBpbiB0aGUgZmls
 ZXN5c3RlbS4KICAqCiAgKiBBIHByZWZlcmVuY2UgbWF5IGJlIG9wdGlvbmFs
 bHkgc3BlY2lmaWVkLiBJZiBhIHByZWZlcmVuY2UgaXMgZ2l2ZW4KICAqIHRo
 ZSBmb2xsb3dpbmcgaGllcmFyY2h5IGlzIHVzZWQgdG8gYWxsb2NhdGUgYSBi
 bG9jazoKQEAgLTEwMiw3ICsxMDIsNyBAQAogCXN0cnVjdCBtX2V4dDJmcyAq
 ZnM7CiAJc3RydWN0IGV4dDJtb3VudCAqdW1wOwogCWludDMyX3QgYm5vOwot
 CWludCBjZzsJCisJdV9pbnQgY2c7CQogCSpibnAgPSAwOwogCWZzID0gaXAt
 PmlfZTJmczsKIAl1bXAgPSBpcC0+aV91bXA7CkBAIC0xMzcsOCArMTM3LDgg
 QEAKICAgICAgICAgfQogbm9zcGFjZToKIAlFWFQyX1VOTE9DSyh1bXApOwot
 CWV4dDJfZnNlcnIoZnMsIGNyZWQtPmNyX3VpZCwgImZpbGUgc3lzdGVtIGZ1
 bGwiKTsKLQl1cHJpbnRmKCJcbiVzOiB3cml0ZSBmYWlsZWQsIGZpbGUgc3lz
 dGVtIGlzIGZ1bGxcbiIsIGZzLT5lMmZzX2ZzbW50KTsKKwlleHQyX2ZzZXJy
 KGZzLCBjcmVkLT5jcl91aWQsICJmaWxlc3lzdGVtIGZ1bGwiKTsKKwl1cHJp
 bnRmKCJcbiVzOiB3cml0ZSBmYWlsZWQsIGZpbGVzeXN0ZW0gaXMgZnVsbFxu
 IiwgZnMtPmUyZnNfZnNtbnQpOwogCXJldHVybiAoRU5PU1BDKTsKIH0KIApA
 QCAtMzMyLDcgKzMzMiw3IEBACiB9CiAKIC8qCi0gKiBBbGxvY2F0ZSBhbiBp
 bm9kZSBpbiB0aGUgZmlsZSBzeXN0ZW0uCisgKiBBbGxvY2F0ZSBhbiBpbm9k
 ZSBpbiB0aGUgZmlsZXN5c3RlbS4KICAqIAogICovCiBpbnQKQEAgLTM0Nyw3
 ICszNDcsOCBAQAogCXN0cnVjdCBpbm9kZSAqaXA7CiAJc3RydWN0IGV4dDJt
 b3VudCAqdW1wOwogCWlub190IGlubywgaXByZWY7Ci0JaW50IGksIGVycm9y
 LCBjZzsKKwl1X2ludCBjZzsKKwlpbnQgaSwgZXJyb3I7CiAJCiAJKnZwcCA9
 IE5VTEw7CiAJcGlwID0gVlRPSShwdnApOwpAQCAtNDMzLDExICs0MzQsMTEg
 QEAKIGV4dDJfZGlycHJlZihzdHJ1Y3QgaW5vZGUgKnBpcCkKIHsKIAlzdHJ1
 Y3QgbV9leHQyZnMgKmZzOwotICAgICAgICBpbnQgY2csIHByZWZjZywgZGly
 c2l6ZSwgY2dzaXplOwotCWludCBhdmdpZnJlZSwgYXZnYmZyZWUsIGF2Z25k
 aXIsIGN1cmRpcnNpemU7Ci0JaW50IG1pbmlmcmVlLCBtaW5iZnJlZSwgbWF4
 bmRpcjsKLQlpbnQgbWluY2csIG1pbm5kaXI7Ci0JaW50IG1heGNvbnRpZ2Rp
 cnM7CisgICAgICAgIHVfaW50IGNnLCBwcmVmY2csIGRpcnNpemUsIGNnc2l6
 ZTsKKwl1X2ludCBhdmdpZnJlZSwgYXZnYmZyZWUsIGF2Z25kaXIsIGN1cmRp
 cnNpemU7CisJdV9pbnQgbWluaWZyZWUsIG1pbmJmcmVlLCBtYXhuZGlyOwor
 CXVfaW50IG1pbmNnLCBtaW5uZGlyOworCXVfaW50IG1heGNvbnRpZ2RpcnM7
 CiAKIAltdHhfYXNzZXJ0KEVYVDJfTVRYKHBpcC0+aV91bXApLCBNQV9PV05F
 RCk7CiAJZnMgPSBwaXAtPmlfZTJmczsKQEAgLTU4NCwxMiArNTg1LDEyIEBA
 CiAgKiAgIDMpIGJydXRlIGZvcmNlIHNlYXJjaCBmb3IgYSBmcmVlIGJsb2Nr
 LgogICovCiBzdGF0aWMgdV9sb25nCi1leHQyX2hhc2hhbGxvYyhzdHJ1Y3Qg
 aW5vZGUgKmlwLCBpbnQgY2csIGxvbmcgcHJlZiwgaW50IHNpemUsCitleHQy
 X2hhc2hhbGxvYyhzdHJ1Y3QgaW5vZGUgKmlwLCB1X2ludCBjZywgbG9uZyBw
 cmVmLCBpbnQgc2l6ZSwKICAgICAgICAgICAgICAgICBkYWRkcl90ICgqYWxs
 b2NhdG9yKShzdHJ1Y3QgaW5vZGUgKiwgaW50LCBkYWRkcl90LCBpbnQpKQog
 ewogCXN0cnVjdCBtX2V4dDJmcyAqZnM7CiAJaW5vX3QgcmVzdWx0OwotCWlu
 dCBpLCBpY2cgPSBjZzsKKwl1X2ludCBpLCBpY2cgPSBjZzsKIAogCW10eF9h
 c3NlcnQoRVhUMl9NVFgoaXAtPmlfdW1wKSwgTUFfT1dORUQpOwogCWZzID0g
 aXAtPmlfZTJmczsKQEAgLTYzNCw3ICs2MzUsNyBAQAogICogYW5kIGlmIGl0
 IGlzLCBhbGxvY2F0ZSBpdC4KICAqLwogc3RhdGljIGRhZGRyX3QKLWV4dDJf
 YWxsb2NjZyhzdHJ1Y3QgaW5vZGUgKmlwLCBpbnQgY2csIGRhZGRyX3QgYnBy
 ZWYsIGludCBzaXplKQorZXh0Ml9hbGxvY2NnKHN0cnVjdCBpbm9kZSAqaXAs
 IHVfaW50IGNnLCBkYWRkcl90IGJwcmVmLCBpbnQgc2l6ZSkKIHsKIAlzdHJ1
 Y3QgbV9leHQyZnMgKmZzOwogCXN0cnVjdCBidWYgKmJwOwpAQCAtNzI0LDcg
 KzcyNSw3IEBACiAgKiBhbGxvY2F0ZSBpdCB1c2luZyB0b2RlIGluIHRoZSBz
 cGVjaWZpZWQgY3lsaW5kZXIgZ3JvdXAuCiAgKi8KIHN0YXRpYyBkYWRkcl90
 Ci1leHQyX25vZGVhbGxvY2NnKHN0cnVjdCBpbm9kZSAqaXAsIGludCBjZywg
 ZGFkZHJfdCBpcHJlZiwgaW50IG1vZGUpCitleHQyX25vZGVhbGxvY2NnKHN0
 cnVjdCBpbm9kZSAqaXAsIHVfaW50IGNnLCBkYWRkcl90IGlwcmVmLCBpbnQg
 bW9kZSkKIHsKIAlzdHJ1Y3QgbV9leHQyZnMgKmZzOwogCXN0cnVjdCBidWYg
 KmJwOwpAQCAtNzkwLDcgKzc5MSw3IEBACiAJfQogCUVYVDJfVU5MT0NLKHVt
 cCk7CiAJYmR3cml0ZShicCk7Ci0JcmV0dXJuIChjZyAqIGZzLT5lMmZzLT5l
 MmZzX2lwZyArIGlwcmVmICsxKTsKKwlyZXR1cm4gKChpbm9fdCljZyAqIGZz
 LT5lMmZzLT5lMmZzX2lwZyArIGlwcmVmICsxKTsKIH0KIAogLyoKQEAgLTgw
 Niw3ICs4MDcsOCBAQAogCXN0cnVjdCBtX2V4dDJmcyAqZnM7CiAJc3RydWN0
 IGJ1ZiAqYnA7CiAJc3RydWN0IGV4dDJtb3VudCAqdW1wOwotCWludCBjZywg
 ZXJyb3I7CisJdV9pbnQgY2c7CisJaW50IGVycm9yOwogCWNoYXIgKmJicDsK
 IAogCWZzID0gaXAtPmlfZTJmczsKQEAgLTk0Miw3ICs5NDQsNyBAQAogfQog
 CiAvKgotICogRnNlcnIgcHJpbnRzIHRoZSBuYW1lIG9mIGEgZmlsZSBzeXN0
 ZW0gd2l0aCBhbiBlcnJvciBkaWFnbm9zdGljLgorICogRnNlcnIgcHJpbnRz
 IHRoZSBuYW1lIG9mIGEgZmlsZXN5c3RlbSB3aXRoIGFuIGVycm9yIGRpYWdu
 b3N0aWMuCiAgKiAKICAqIFRoZSBmb3JtIG9mIHRoZSBlcnJvciBtZXNzYWdl
 IGlzOgogICoJZnM6IGVycm9yIG1lc3NhZ2UK
 
 --0-1240140841-1265856988=:21423--
State-Changed-From-To: open->closed 
State-Changed-By: pfg 
State-Changed-When: Sat Jan 11 01:10:18 UTC 2014 
State-Changed-Why:  
There is a new BSD-licensed implementation with several recent changes  
that take care of any possible overflow in case of many directories. 
Unfortunately it doesn't seem possible to implement the ext4 option to  
support more than 32000 directories in FreeBSD but we shouldn't have  
problems handling the normal ext2/ext3 directories. 

GNATS: Enter the reason for changing this  
PR's state here. GNATS: Lines beginning with "GNATS:" will be deleted. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=142597 
>Unformatted:
