Messages in this thread | | | Date | Thu, 01 Aug 2013 18:21:42 +0200 | From | Bernd Schubert <> | Subject | Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition |
| |
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.
| |