On May 31, 2007 17:33 -0400, Theodore Tso wrote:
> Oops, I just pushed a set of bugfixes to Linux that included the
> superblock field reservations.
Oh well.
> What is in the e2fsprogs hg repository ... is:
>
> ..
> __u16 s_raid_stride; /* RAID stride */
> __u16 s
Theodore Tso wrote:
And has anyone investigated where there are
magic ioctl's or libdevmapper APi's so we can get the RAID parameters
automatically? If so, patches so that mke2fs can get the information
automatically (as opposed to forcing the user to have to specify lots
of annoying options) wo
On Thu, May 31, 2007 at 02:19:02PM -0600, Andreas Dilger wrote:
> Ah, we've been doing it the other way around here. It makes sense to keep
> the s_raid_stripe_width fields together. I think this code is preliminary
> enough that nobody has actually started using it yet. Can you please post
> wh
On Thu, 2007-05-31 at 14:19 -0600, Andreas Dilger wrote:
> On May 31, 2007 12:21 -0400, Theodore Tso wrote:
> > On Thu, May 24, 2007 at 07:45:32PM +0530, Rupesh Thakare wrote:
> > > I've added "s_raid_stripe_width" parameter in superblock.
> > > I've also incorporated "s_raid_stride" and "s_raid_s
On May 31, 2007 12:21 -0400, Theodore Tso wrote:
> On Thu, May 24, 2007 at 07:45:32PM +0530, Rupesh Thakare wrote:
> > I've added "s_raid_stripe_width" parameter in superblock.
> > I've also incorporated "s_raid_stride" and "s_raid_stripe_width"
> > parameters in tune2fs.
> > The new options can
On Thu, May 24, 2007 at 07:45:32PM +0530, Rupesh Thakare wrote:
> Hello,
> I've added "s_raid_stripe_width" parameter in superblock.
> I've also incorporated "s_raid_stride" and "s_raid_stripe_width"
> parameters in tune2fs.
> The new options can be specified using '-E options' in both mke2fs and
Hello,
I've added "s_raid_stripe_width" parameter in superblock.
I've also incorporated "s_raid_stride" and "s_raid_stripe_width"
parameters in tune2fs.
The new options can be specified using '-E options' in both mke2fs and
tune2fs.
Both the Man pages (mke2fs and tune2fs) are updated according
On May 22, 2007 01:22 +0530, Kalpak Shah wrote:
> __u16 s_raid_stride; /* RAID stride */
> - __u16 s_pad; /* Padding */
> + __u16 s_mmp_interval; /* Wait for # seconds in MMP
> checking */
> + __u64 s_mmp_block;/* Bloc
On Fri, May 11, 2007 at 07:02:48PM -0700, Andreas Dilger wrote:
> It is possible to specify the RAID stride to mke2fs allow it to optimize
> the layout of the bitmaps. With the new mballoc it is also possible to
> tell it via a mount option to do large allocations aligned on the RAID
> stride (by
> > Perhaps the filesystem driver or mkfs could
> > probe for the stride in those cases? If the code asks for, say, 10MiB of
> > data from the block device and it gets back sectors that are spaced
> > 128KiB apart before it gets the rest of the data, it can make an
> > intelligent guess about the s
On May 12, 2007 01:11 -0700, Eric wrote:
> The concept is really tempting. RAID is good, and not asking the user
> for information that the system can find out for itself is good too.
>
> In the unlikely event that the RAID stride were to change, I think the
> autodetect-each-time method would be
I don't quite follow? how would you "probe" ? for example,
there is DDN array which write well with 1MB aligned/sized
requests only. thus, mballoc tries to align allocation
requests WRT to this constrain. do you mean incorporation
storage benchmark in the mount procedure?
thanks, Alex
Eric wrote
On Sat, 2007-05-12 at 12:33 +0400, Alex Tomas wrote:
> > In the unlikely event that the RAID stride were to change, I think the
> > autodetect-each-time method would be superior to the store-in-superblock
> > method.
>
> true, but in some cases (hardware raid, SAN, etc) there is no easy way
> to l
Eric wrote:
The concept is really tempting. RAID is good, and not asking the user
for information that the system can find out for itself is good too.
In the unlikely event that the RAID stride were to change, I think the
autodetect-each-time method would be superior to the store-in-superblock
On Fri, 2007-05-11 at 19:02 -0700, Andreas Dilger wrote:
> What would be rather convenient is to store the RAID stride value in the
> superblock.
> There is also a library used in the XFS tools that knows how to probe various
> kinds of block devices (e.g. MD RAID, LVM/DM, etc) to get their storage
Andreas Dilger wrote:
It is possible to specify the RAID stride to mke2fs allow it to optimize
the layout of the bitmaps. With the new mballoc it is also possible to
tell it via a mount option to do large allocations aligned on the RAID
stride (by default it aligns on 1MB boundaries from the sta
It is possible to specify the RAID stride to mke2fs allow it to optimize
the layout of the bitmaps. With the new mballoc it is also possible to
tell it via a mount option to do large allocations aligned on the RAID
stride (by default it aligns on 1MB boundaries from the start of the LUN).
What wo
17 matches
Mail list logo
