CAM already does this, doesn't really help with speed as much as you
might think though.
On 04/10/2016 19:53, Maxim Sobolev wrote:
For the whole disk destruction, hopefully one day we'd have BIO_DELETE
coalesce code, so that you can batch of lot of operations into handful SATA
commands. I've he
For the whole disk destruction, hopefully one day we'd have BIO_DELETE
coalesce code, so that you can batch of lot of operations into handful SATA
commands. I've heard rumours imp@ was doing something along those lines. As
well as SSD disks smart enough to process those requests in the background.
On Tuesday, October 04, 2016 06:23:26 AM Warren Block wrote:
> On Mon, 26 Sep 2016, John Baldwin wrote:
>
> > On Tuesday, September 27, 2016 12:36:22 AM Ngie Cooper wrote:
> >>
> >>> On Sep 26, 2016, at 22:48, Ernie Luzar wrote:
> >>
> >> ...
> >>
> >>> This little script has been posted before.
On Mon, 26 Sep 2016, John Baldwin wrote:
On Tuesday, September 27, 2016 12:36:22 AM Ngie Cooper wrote:
On Sep 26, 2016, at 22:48, Ernie Luzar wrote:
...
This little script has been posted before. Maybe it will be what your looking
for. Called gpart.nuke
#! /bin/sh
echo "What disk do yo
On Thursday, September 29, 2016 01:01:44 AM Andriy Gapon wrote:
> On 28/09/2016 21:08, Andrey V. Elsukov wrote:
> > This is very strange problem, how did you created MBR if you have not
> > destroyed GPT? :)
>
> Using a tool that's not aware of GPT at all?
I think the drive's arrived with some pa
On 28/09/2016 21:08, Andrey V. Elsukov wrote:
> This is very strange problem, how did you created MBR if you have not
> destroyed GPT? :)
Using a tool that's not aware of GPT at all?
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://
On 28.09.2016 22:02, Allan Jude wrote:
> I wonder if this issue is related at all to the new 'auto resize' gpart
> bits. That leaves the 'uncommitted' transaction pending, and may require
> a 'gpart undo' before the other commands will work correctly.
All other commands that do any changes will is
On Wed, Sep 28, 2016 at 1:02 PM, Allan Jude wrote:
> On 2016-09-27 01:58, Warner Losh wrote:
>> On Mon, Sep 26, 2016 at 11:06 PM, O'Connor, Daniel
>> wrote:
>>>
On 27 Sep 2016, at 14:28, Warner Losh wrote:
dd of 2MB of zeros to the start and end of the disk. That will destroy
pre
On 2016-09-27 01:58, Warner Losh wrote:
> On Mon, Sep 26, 2016 at 11:06 PM, O'Connor, Daniel wrote:
>>
>>> On 27 Sep 2016, at 14:28, Warner Losh wrote:
>>> dd of 2MB of zeros to the start and end of the disk. That will destroy
>>> pretty much everything. For SSDs, sometimes you can do the same wi
On 26.09.2016 23:51, John Baldwin wrote:
>> Why not just use "gpart destroy -F provider"?
>
> That doesn't always work. In particular, if a disk was partitioned with GPT
> and then you use normal MBR on it afterwards, the 'gpart destroy -F' of the
> MBR will leave most of the GPT intact and the d
On Mon, Sep 26, 2016 at 11:06 PM, O'Connor, Daniel wrote:
>
>> On 27 Sep 2016, at 14:28, Warner Losh wrote:
>> dd of 2MB of zeros to the start and end of the disk. That will destroy
>> pretty much everything. For SSDs, sometimes you can do the same with
>> TRIMs only faster (other times they are
> On 27 Sep 2016, at 14:28, Warner Losh wrote:
> dd of 2MB of zeros to the start and end of the disk. That will destroy
> pretty much everything. For SSDs, sometimes you can do the same with
> TRIMs only faster (other times they are slower or unreliable).
Yeah, but it would be nicer to not have
On Mon, Sep 26, 2016 at 8:46 PM, O'Connor, Daniel wrote:
>
>> On 27 Sep 2016, at 06:21, John Baldwin wrote:
>> That doesn't always work. In particular, if a disk was partitioned with GPT
>> and then you use normal MBR on it afterwards, the 'gpart destroy -F' of the
>> MBR will leave most of the
On Tue, 27 Sep 2016 00:36:22 +0900
Ngie Cooper wrote:
> > On Sep 26, 2016, at 22:48, Ernie Luzar wrote:
>
> ...
>
> > This little script has been posted before. Maybe it will be what your
> > looking for. Called gpart.nuke
> >
> > #! /bin/sh
> > echo "What disk do you want"
> > echo "to wip
On Mon, 26 Sep 2016 09:48:22 -0400
Ernie Luzar wrote:
> Hartmann, O. wrote:
> > I ran into a very nasty and time consuming problem. Creating a NanoBSD
> > image with a modified script framework creating GPT partitions, I put
> > the imaes via "dd(1)" on USB flash or SD flash. Because the images a
> On 27 Sep 2016, at 06:21, John Baldwin wrote:
> That doesn't always work. In particular, if a disk was partitioned with GPT
> and then you use normal MBR on it afterwards, the 'gpart destroy -F' of the
> MBR will leave most of the GPT intact and the disk will come up with the old
> GPT partiti
On Tuesday, September 27, 2016 12:36:22 AM Ngie Cooper wrote:
>
> > On Sep 26, 2016, at 22:48, Ernie Luzar wrote:
>
> ...
>
> > This little script has been posted before. Maybe it will be what your
> > looking for. Called gpart.nuke
> >
> > #! /bin/sh
> > echo "What disk do you want"
> > echo
> On Sep 26, 2016, at 22:48, Ernie Luzar wrote:
...
> This little script has been posted before. Maybe it will be what your looking
> for. Called gpart.nuke
>
> #! /bin/sh
> echo "What disk do you want"
> echo "to wipe? For example - da1 :"
> read disk
> echo "OK, in 10 seconds I will destroy
On 09/26/2016 11:08, Gary Jennejohn wrote:
> On Mon, 26 Sep 2016 09:48:22 -0400
> Ernie Luzar wrote:
>
>> Hartmann, O. wrote:
>>> I ran into a very nasty and time consuming problem. Creating a NanoBSD
>>> image with a modified script framework creating GPT partitions, I put
>>> the imaes via "dd(
On Mon, 26 Sep 2016 09:48:22 -0400
Ernie Luzar wrote:
> Hartmann, O. wrote:
> > I ran into a very nasty and time consuming problem. Creating a NanoBSD
> > image with a modified script framework creating GPT partitions, I put
> > the imaes via "dd(1)" on USB flash or SD flash. Because the images a
Hartmann, O. wrote:
I ran into a very nasty and time consuming problem. Creating a NanoBSD
image with a modified script framework creating GPT partitions, I put
the imaes via "dd(1)" on USB flash or SD flash. Because the images are
usually much smaller than the overall capacity of the USB or SD,
Hartmann, O. wrote on 09/26/2016 15:01:
[...]
Using a fresh/new SD or USB resolves the problem. But the question
remains: how can I destroy any relevant GPT information on a Flash
drive (or even harddisk) to avoid unwanted remains of an foul image
installation?
First guess was to write the las
I ran into a very nasty and time consuming problem. Creating a NanoBSD
image with a modified script framework creating GPT partitions, I put
the imaes via "dd(1)" on USB flash or SD flash. Because the images are
usually much smaller than the overall capacity of the USB or SD, the OS
(FreeBSD CURREN
23 matches
Mail list logo
