Bug 142597 - [ext2fs] ext2fs does not work on filesystems with really big directories
Summary: [ext2fs] ext2fs does not work on filesystems with really big directories
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-10 21:40 UTC by Slawomir Wojciech Wojtczak
Modified: 2014-01-11 01:15 UTC (History)
0 users

See Also:


Attachments
patch-ext2_alloc.c (1.33 KB, application/octet-stream)
2010-02-04 18:33 UTC, Pedro F. Giffuni
no flags Details
patch-ext2_alloc.c (3.76 KB, application/octet-stream)
2010-02-11 02:56 UTC, Pedro F. Giffuni
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Slawomir Wojciech Wojtczak 2010-01-10 21:40:01 UTC
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
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-01-10 21:43:16 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 aditya sarawgi 2010-01-25 21:54:54 UTC
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
Comment 3 Slawomir Wojciech Wojtczak 2010-01-26 07:46:15 UTC
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
Comment 4 Pedro F. Giffuni 2010-02-04 18:33:16 UTC
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.


      
Comment 5 Pedro F. Giffuni 2010-02-11 02:56:28 UTC
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.



      
Comment 6 Pedro F. Giffuni freebsd_committer freebsd_triage 2014-01-11 01:10:18 UTC
State Changed
From-To: open->closed

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.