linux-ext4 - Re: Design alternatives for fragments/file tail support in ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061013174739.GX6221@schatzie.adilger.int>
Date:	Fri, 13 Oct 2006 11:47:39 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Theodore Tso <tytso@....edu>
Cc:	Alex Tomas <alex@...sterfs.com>, linux-ext4@...r.kernel.org
Subject: Re: Design alternatives for fragments/file tail support in ext4

On Oct 13, 2006  08:23 -0400, Theodore Tso wrote:
> On Fri, Oct 13, 2006 at 02:56:46PM +0400, Alex Tomas wrote:
> > >>>>> Theodore Tso (TT) writes:
> >  TT> I suggest this be tunable by superblock field, and not by a /proc
> >  TT> tunable.  This is the sort of thing which might be different
> >  TT> per-filesystem, and the algorithm will be most effective if the
> >  TT> filesystem always use the same cluster size from the time when it was
> >  TT> first created.  I'd be happy to assign a superblock field for this
> >  TT> purpose, and add the appropriate tune2fs support if we have general
> >  TT> agreement on this point.
> > 
> > that would be good. there is even a stride option to mke2fs?
> 
> Yes, there is.  And just as we have -E stride=stripe-size and -E
> resize=max-online-resize, we can also -E cluster-size=bytes parameter
> in mke2fs.  It would also make sense to make this be something that
> can be defaulted in /etc/mke2fs.conf, since even for IDE or SATA disks
> it probably makes sense to make the cluster size be 16k or 32k or
> maybe even higher.  We probably need to do some benchmarks to see
> whether or not this makes sense.

I think what Alex meant is that the "mke2fs -E stride=" value should
just be put into the superblock.  This would allow tuning the mballoc code
to match the RAID alignment, and would also make life easier for resizers
so they can continue the RAID-stepping of bitmaps that mke2fs does
without having to extrapolate the stride value from the bitmap locations.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html