EXT3 Users Mailing List

headers John Nelson | 2 Apr 2008 00:46 · /index/

does ext3 allocate space for files anywhere on the disk where there is 
free space or does it try to keep them all in one area like how ntfs or 
fat do?

John Nelson wrote:
> does ext3 allocate space for files anywhere on the disk where there is 
> free space or does it try to keep them all in one area like how ntfs 
> or fat do?
>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users <at> redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users
>
>
In fs/ext3/ialloc.c:

/*
 * There are two policies for allocating an inode.  If the new inode is
 * a directory, then a forward search is made for a block group with both
 * free space and a low directory-to-inode ratio; if that fails, then of
 * the groups with above-average free space, that group with the fewest
 * directories already is chosen.
 *
 * For other inodes, search forward from the parent directory\'s block
 * group to find a free inode.
 */
static int find_group_dir(struct super_block *sb, struct inode *parent)
{
        int ngroups = EXT3_SB(sb)->s_groups_count;
        unsigned int freei, avefreei;
        struct ext3_group_desc *desc, *best_desc = NULL;
        int group, best_group = -1;

Hi,

I have an ext3  file system created with -T largefile4 option. Now it is 
running out of inode but it's only about 10% full.

- Is there a way now to increase the number of inode without making a 
new file system?

- If not, I am thinking about shrinking the file system, and then use 
the free up space to create a new file system with more inodes, and move 
the data over. Since I am already running out of inode, would I still be 
able to shrink the file system?

Thanks,
...
ling

On Mon, 2008-03-31 at 13:18 +0200, Sebastian Reitenbach wrote:
> Hi Nicolas,
> 
> Nicolas KOWALSKI <niko <at> petole.dyndns.org> wrote: 
> > "Sebastian Reitenbach" <sebastia <at> l00-bugdead-prods.de> writes:
> > 
> > > installhost2:~ # time ls -la /mnt/index/ | wc -l
> > >  500005
> > >  
> > >  real 2m41.015s
> > >  user 0m4.568s
> > >  sys 0m6.520s
> > >  
> > >  
> > >  installhost2:~ # time ls -la /mnt/noindex/ | wc -l
> > >  500005
> > >  
> > >  real 0m10.792s
> > >  user 0m3.172s
> > >  sys 0m6.000s
> > >
> > > I expected the dir_index should speedup this a little bit?
> > > I assume I'm still missing sth?
> > 
> > I think the point of dir_index is "only" to quickly find in a large
> > directory a file when you _already_ have its name.
> > 
> > The performance of listing is not its purpose, and as you noted it,
> > even makes performance worse.

On Mon, Apr 07, 2008 at 12:11:18PM -0300, Ranieri Oliveira wrote:
> /usr/include/ext2fs/bitops.h:440: error: invalid conversion from `unsigned
> char*' to `char*'

What is on line 440?

Please keep ext3-users <at> redhat.com in the CC.

--

-- 
Carlo Wood <carlo <at> alinoe.com>

On Mon, Apr 07, 2008 at 05:29:46PM -0300, Ranieri Oliveira wrote:
>     437 _INLINE_ int ext2fs_find_first_bit_set(void * addr, unsigned size)
>     439 {
>     440         char    *cp = (unsigned char *) addr;
>     441         int     res = 0, d0;
>     442
>     443         if (!size)
>     444                 return 0;
>     445
>     446         while ((size > res) && (*cp == 0)) {
>     447                 cp++;
>     448                 res += 8;
>     449         }
>     450         d0 = ffs(*cp);
>     451         if (d0 == 0)
>     452                 return size;
>     453
>     454         return res + d0 - 1;
>     455 }

That is an error in ext2progs.
You can workaround the problem by changing

    char    *cp = (unsigned char *) addr;

into

    char    *cp = (char *) addr;

I'd think that better is to upgrade your ext2progs

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Hello all,

I recently encountered a problem that I thought I should bring to the  
ext3 devs. I've seen some evidence of similar issues in the past, but  
it wasn't clear that anyone had experienced it at quite this scale.

The short summary is that I let 'e2fsck -C 0 -y -f' run for more than  
24 hours on a 4.25Tb filesystem before having to kill it. It had been  
stuck at "70.1%" in Pass 2 (checking directory structure) for about 10  
hours. e2fsck was using about 4.4Gb of RAM and was maxing out 1 CPU  
core (out of 8).

This filesystem is used for disk-to-disk backups with dirvish[1]  The  
volume was 4.25Gb large, and about 90% full. I was doing an fsck prior  
to running resize2fs, as required by said tool. (I ended up switching  
to ext2online, which worked fine.)

I suspect the large # of hard links and the large file system size are  
what did me in. Fortunately, my filesystem is clean for now. What I'm  
worried about is the day when it actually needs a proper fsck to  
correct problems. I have no idea how long the fsck would have taken  
had I not cancelled it. I fear it would have been more than 48hours.

Any suggestions (including undocumented command line options) I can  
try to accelerate this in the future would be welcome. As this system  
is for backups and is idle for about 12-16 hours a day, I can un-mount  
the volume and perform some (non-destructive!!) tests if there is  
interest. Unfortunately, I cannot provide remote access to the system  
for security reasons as this is our backup archive.

I'm using CentOS 4.5 as my distro.

'uname -a' reports:
Linux backups-00.dc-00.rbm.local 2.6.9-55.0.12.ELsmp #1 SMP Fri Nov 2  
12:38:56 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

The underlying hardware is a Dell PE 2950, with a PERC 5i RAID  
controller and 6x 1Tb SATA drives and 8Gb of RAM. I/O performance has  
been fine for my purposes, but I have not benchmarked, tuned or  
tweaked it in any way.

Thanks!

--jeh

[1] Dirvish is an rsync/hardlink based set of perl scripts -- see http://www.dirvish.org/ 
  for more details.

hi

I got a very fragmented video file that is in about 3200 extents. I 
copied the file about 10 times to see if  can get a lower amount of 
extents. Some times i got 30 and sometimes 1000. My drive is 90% free. 
Does ext3 have trouble finding free space for files that are being copied?

The video file is about 600 Megabytes.

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

2	April 2013
19	March 2013
5	January 2013
1	November 2012
1	October 2012
2	September 2012
8	August 2012
4	June 2012
1	April 2012
3	March 2012
1	January 2012
2	December 2011
9	November 2011
1	October 2011
21	September 2011
1	July 2011
20	June 2011
6	May 2011
11	April 2011
29	March 2011
14	February 2011
18	January 2011
18	December 2010
25	November 2010
22	October 2010
3	September 2010
6	August 2010
9	July 2010
11	June 2010
18	May 2010
8	April 2010
44	March 2010
43	February 2010
18	January 2010
20	December 2009
7	November 2009
7	October 2009
19	September 2009
9	August 2009
8	July 2009
72	June 2009
36	May 2009
44	April 2009
41	March 2009
63	February 2009
41	January 2009
50	December 2008
15	November 2008
45	October 2008
69	September 2008
31	August 2008
39	July 2008
70	June 2008
41	May 2008
28	April 2008
77	March 2008
36	February 2008
67	January 2008
15	December 2007
13	November 2007
35	October 2007
54	September 2007
27	August 2007
43	July 2007
29	June 2007
55	May 2007
48	April 2007
61	March 2007
43	February 2007
26	January 2007
35	December 2006
46	November 2006
54	October 2006
55	September 2006
47	August 2006
41	July 2006
45	June 2006
30	May 2006
88	April 2006
37	March 2006
23	February 2006
43	January 2006
29	December 2005
54	November 2005
21	October 2005
27	September 2005
13	August 2005
33	July 2005
45	June 2005
33	May 2005
36	April 2005
37	March 2005
72	February 2005
35	January 2005
36	December 2004
16	November 2004
23	October 2004
35	September 2004
15	August 2004
54	July 2004
54	June 2004
40	May 2004
69	April 2004
123	March 2004
64	February 2004
49	January 2004
57	December 2003
45	November 2003
50	October 2003
36	September 2003
74	August 2003
50	July 2003
120	June 2003
97	May 2003
99	April 2003
132	March 2003
146	February 2003
102	January 2003
133	December 2002
104	November 2002
174	October 2002
164	September 2002

allocation

Re: allocation

Shrink ext3 filesystem , running out of inode questions

Re: with dir_index ls is slower than without?

Re: [ext3grep] Re: Error compiling on Cent OS 4

Re: [ext3grep] Re: Error compiling on Cent OS 4

Re: [ext3grep] Re: Error compiling on Cent OS 4

Extremely long FSCK. (>24 hours)

copying

Re: Extremely long FSCK. (>24 hours)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30