Hi,
On Fri, Jan 05, 2001 at 12:06:47AM -0700, Andreas Dilger wrote:
> Stephen, you write:
> > On Thu, Jan 04, 2001 at 05:31:12PM -0500, Alexander Viro wrote:
> > > BTW, what inumber do you want for whiteouts? IIRC, we decided to use
> > > the same entry type as UFS does (14), but I don't remember
Stephen, you write:
> On Thu, Jan 04, 2001 at 05:31:12PM -0500, Alexander Viro wrote:
> > BTW, what inumber do you want for whiteouts? IIRC, we decided to use
> > the same entry type as UFS does (14), but I don't remember what was
> > the decision on inumber. UFS uses 1 for them, is it OK with you
Hi,
On Thu, Jan 04, 2001 at 05:31:12PM -0500, Alexander Viro wrote:
>
> BTW, what inumber do you want for whiteouts? IIRC, we decided to use
> the same entry type as UFS does (14), but I don't remember what was
> the decision on inumber. UFS uses 1 for them, is it OK with you?
0 is used for pad
On Thu, 4 Jan 2001, Alexander Viro wrote:
> Al, putting together fs patches for -bird...
Al,
Have you added Chris Mason patch to SetPageDirty in mark_buffer_dirty() &
related changes to your -bird tree ?
Also, would you accept a patch to remove mark_buffer_dirty() (and use
__mark_buffer_d
On Thu, 4 Jan 2001, Stephen C. Tweedie wrote:
> The problem with directories is that they don't always grow rapidly
> like that. Spool directories are perfect examples of directories
> which grow sporadically over a long time, which is why we wanted
> persistent preallocation.
OK... It could
Hi,
On Wed, Jan 03, 2001 at 11:12:48AM -0500, Alexander Viro wrote:
>
> On Wed, 3 Jan 2001, Stephen C. Tweedie wrote:
>
> > Having preallocated blocks allocated immediately is deliberate:
> > directories grow slowly and remain closed most of the time, so the
> > normal preallocation regime of o
On Thu, 4 Jan 2001, Alexander Viro wrote:
> > I bet it long predates dcache though..
>
> Not too likely. It went in in 2.1.93. Apr 2 1998...
> Dcache was there ~50 versions before that.
Huh. Is there anything that prevents fragmentation in, say, growing
maildirs, where there's nothing but local
On Wed, 3 Jan 2001, Oliver Xymoron wrote:
> On Wed, 3 Jan 2001, Alexander Viro wrote:
>
> > On Wed, 3 Jan 2001, Stephen C. Tweedie wrote:
> >
> > > Having preallocated blocks allocated immediately is deliberate:
> > > directories grow slowly and remain closed most of the time, so the
> > > nor
On Wed, 3 Jan 2001, Alexander Viro wrote:
> On Wed, 3 Jan 2001, Stephen C. Tweedie wrote:
>
> > Having preallocated blocks allocated immediately is deliberate:
> > directories grow slowly and remain closed most of the time, so the
> > normal preallocation regime of only preallocating open files a
Al, you write:
> Folks, there is a pretty strange detail of the allocation policy -
> if cylinder group has no free blocks past the goal ext2 tries very hard to
> avoid allocation in the beginning of the group. I.e. order looks so:
>
> * goal
> * goal .. (goal+63) & ~63
>
On Wed, 3 Jan 2001, Stephen C. Tweedie wrote:
> Having preallocated blocks allocated immediately is deliberate:
> directories grow slowly and remain closed most of the time, so the
> normal preallocation regime of only preallocating open files and
> discarding preallocation on close just doesn'
Hi,
On Tue, Jan 02, 2001 at 10:37:50PM -0500, Alexander Viro wrote:
> Umm... OK, the last argument is convincing. Thanks...
>
> BTW, what was the reason behind doing preallocation for directories on
> ext2_bread() level? We both buy ourselves an oddity in directory structure
> (preallocated blo
On Tue, 2 Jan 2001, Andreas Dilger wrote:
> This predates me by a while, but I suspect that it is done this way on
> the assumption it is easier to seek forward on the disk while reading
> a file rather than seeking backwards. Also, since with new inodes the
> goal is initially the first block
Folks, there is a pretty strange detail of the allocation policy -
if cylinder group has no free blocks past the goal ext2 tries very hard to
avoid allocation in the beginning of the group. I.e. order looks so:
* goal
* goal .. (goal+63) & ~63
* goal .. end of cyli
14 matches
Mail list logo
