Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup/ early userspace transition

[Bernd Schubert]

On 08/01/2013 06:04 PM, Nix wrote:
> On 1 Aug 2013, Bernd Schubert verbalised:
>
> > On 07/30/2013 11:20 PM, Nix wrote:
> > > On 30 Jul 2013, Bernd Schubert told this:
> > >
> > > > On 07/30/2013 02:56 AM, Nix wrote:
> > > > > On 30 Jul 2013, Douglas Gilbert outgrape:
> > > > >
> > > > > > Please supply the information that Martin Petersen asked
> > > > > > for.
> > > > >
> > > > > Did it in private IRC (the advantage of working for the same division of
> > > > > the same company!)
> > > > >
> > > > > I didn't realise the original fix was actually implemented to allow
> > > > > Bernd, with a different Areca controller, to boot... obviously, in that
> > > > > situation, reversion is wrong, since that would just replace one won't-
> > > > > boot situation with another.
> > > >
> > > > Unless there is very simple fix the commit should reverted, imho. It
> > > > would better then to remove write-same support from the md-layer.
> > >
> > > I'm not using md on that machine, just LVM. Our suspicion is that ext4
> > > is doing a WRITE SAME for some reason.
> >
> > I didn't check yet for other cases, mkfs.ext4 does WRITE SAME and with
> > lazy init it also will happen after mounting the file system, while
> > lazy init is running (inode zeroing).
>
> Well, it'll happen the first few times you mount the fs. If your fs is
> years old (as mine are) the inode tables will probably have been
> initialized by now!

I'm frequently doing tests with millions of files and reformating is 
ways faster than deleting the all these files.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/