lkml.org 
[lkml]   [2013]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2013-08-01 18:41    [W:0.194 / U:25.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site