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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 01 Aug 2013 18:21:42 +0200
From:	Bernd Schubert <bernd.schubert@...tmail.fm>
To:	Nix <nix@...eri.org.uk>
CC:	Douglas Gilbert <dgilbert@...erlog.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-scsi@...r.kernel.org,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	nick.cheng@...ca.com.tw, stable@...r.kernel.org
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ