All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Lord <lord@xfs.org>
To: David Chinner <dgc@sgi.com>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: Directories > 2GB
Date: Mon, 09 Oct 2006 21:15:28 -0500	[thread overview]
Message-ID: <452B0240.60203@xfs.org> (raw)
In-Reply-To: <20061010015512.GQ11034@melbourne.sgi.com>

Hi Dave,

My recollection is that it used to default to on, it was disabled
because it needs to map the buffer into a single contiguous chunk
of kernel memory. This was placing a lot of pressure on the memory
remapping code, so we made it not default to on as reworking the
code to deal with non contig memory was looking like a major
effort.

Steve


David Chinner wrote:
> On Mon, Oct 09, 2006 at 04:53:02PM -0500, Steve Lord wrote:
>> You might want to think about keeping the directory a little
>> more contiguous than individual disk blocks. XFS does have
>> code in it to allocate the directory in chunks larger than
>> a single file system block. It does not get used on linux
>> because the code was written under the assumption you can
>> see the whole chunk as a single piece of memory which does not
>> work to well in the linux kernel.
> 
> This code is enabled and seems to work in Linux. I don't know if it
> passes xfsqa  so I don't know how reliable this feature is. TO check
> it all I did was run a quick test on a x86_64 kernel (4k page
> size) using 16k directory blocks (4 pages):



> 
> # mkfs.xfs -f -n size=16384 /dev/ubd/1
> .....
> # xfs_db -r -c "sb 0" -c "p dirblklog" /dev/ubd/1
> dirblklog = 2
> # mount /dev/ubd/1 /mnt/xfs
> # for i in `seq 0 1 100000`; do touch fred.$i; done
> # umount /mnt/xfs
> # mount /mnt/xfs
> # ls /mnt/xfs |wc -l
> 100000
> # rm -rf /mnt/xfs/*
> # ls /mnt/xfs |wc -l
> 0
> # umount /mnt/xfs
> #
> 
> Cheers,
> 
> Dave.


  parent reply	other threads:[~2006-10-10  2:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-04 16:56 Directories > 2GB Andreas Dilger
2006-10-04 17:51 ` Dave Kleikamp
2006-10-04 19:09 ` Peter Grandi
2006-10-09 21:53 ` Steve Lord
2006-10-10  1:55   ` David Chinner
2006-10-10  2:07     ` Nathan Scott
2006-10-10  2:15     ` Steve Lord [this message]
2006-10-10  9:19       ` Christoph Hellwig
2006-10-10 23:31         ` David Chinner
2006-10-11 16:49           ` Steve Lord
2006-10-12  0:26             ` David Chinner
     [not found]           ` <452D2086.2020204__28695.6273987473$1160585745$gmane$org@xfs.org>
2006-10-16 18:17             ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=452B0240.60203@xfs.org \
    --to=lord@xfs.org \
    --cc=dgc@sgi.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.