I happened across the disable TRIM option. This is relevant when writing an image TO an SSD, right, since I assume write caching can only take place on a partition not being backed up? I just want to ensure it's N/A when an SSD is what's being backed up.
"Disable TRIM – Reduces the amount of caching required on systems with TRIM
enabled by disabling TRIM during the copy operation. Note: If the operation doesn’t
complete (due to reboot, shutdown, process forced to end, etc.) TRIM will stay
disabled until enabled using the Windows fsutil program (fsutil behavior set
DisableDeleteNotify 0). If IFW completes the operation, even with errors
reported, TRIM will be properly reset to the enabled state."
TRIM
-
TeraByte Support
- Posts: 3625
- Joined: Thu May 05, 2011 10:37 pm
Re: TRIM
No, it's on what is being backed up.
"rseiler" wrote in message news:4237@public.image...
I happened across the disable TRIM option. This is relevant when writing an
image TO an SSD, right, since I assume write caching can only take place on
a partition not being backed up? I just want to ensure it's N/A when an SSD
is what's being backed up.
"Disable TRIM - Reduces the amount of caching required on systems with TRIM
enabled by disabling TRIM during the copy operation. Note: If the operation
doesn't
complete (due to reboot, shutdown, process forced to end, etc.) TRIM will
stay
disabled until enabled using the Windows fsutil program (fsutil behavior set
DisableDeleteNotify 0). If IFW completes the operation, even with errors
reported, TRIM will be properly reset to the enabled state."
"rseiler" wrote in message news:4237@public.image...
I happened across the disable TRIM option. This is relevant when writing an
image TO an SSD, right, since I assume write caching can only take place on
a partition not being backed up? I just want to ensure it's N/A when an SSD
is what's being backed up.
"Disable TRIM - Reduces the amount of caching required on systems with TRIM
enabled by disabling TRIM during the copy operation. Note: If the operation
doesn't
complete (due to reboot, shutdown, process forced to end, etc.) TRIM will
stay
disabled until enabled using the Windows fsutil program (fsutil behavior set
DisableDeleteNotify 0). If IFW completes the operation, even with errors
reported, TRIM will be properly reset to the enabled state."
Re: TRIM
OK, could you maybe give a bit more background on this then? I don't quite see the connection between disabling TRIM and reducing IFW's caching. I understand why you'd want to minimize writes to SSD when possible, but how does temporarily disabling TRIM accomplish that?
Does the absence of the option in IFD (DOS doesn't support TRIM) mean IFD avoids caching in DOS with SSDs? If it doesn't, would this suggest it's not the best idea to be using IFD (or IFL, apparently) for backing up SSDs?
How much caching are we talking about (let's use the example of 30GB used on a 60GB SSD)?
TeraByte Support wrote:
> No, it's on what is being backed up.
>
> "rseiler" wrote in message news:4237@public.image...
>
> I happened across the disable TRIM option. This is relevant when writing an
> image TO an SSD, right, since I assume write caching can only take place on
> a partition not being backed up? I just want to ensure it's N/A when an
> SSD is what's being backed up.
>
> "Disable TRIM - Reduces the amount of caching required on systems with
> TRIM enabled by disabling TRIM during the copy operation. Note: If the operation
> doesn't complete (due to reboot, shutdown, process forced to end, etc.) TRIM will
> stay disabled until enabled using the Windows fsutil program (fsutil behavior
> set DisableDeleteNotify 0). If IFW completes the operation, even with errors
> reported, TRIM will be properly reset to the enabled state."
Does the absence of the option in IFD (DOS doesn't support TRIM) mean IFD avoids caching in DOS with SSDs? If it doesn't, would this suggest it's not the best idea to be using IFD (or IFL, apparently) for backing up SSDs?
How much caching are we talking about (let's use the example of 30GB used on a 60GB SSD)?
TeraByte Support wrote:
> No, it's on what is being backed up.
>
> "rseiler" wrote in message news:4237@public.image...
>
> I happened across the disable TRIM option. This is relevant when writing an
> image TO an SSD, right, since I assume write caching can only take place on
> a partition not being backed up? I just want to ensure it's N/A when an
> SSD is what's being backed up.
>
> "Disable TRIM - Reduces the amount of caching required on systems with
> TRIM enabled by disabling TRIM during the copy operation. Note: If the operation
> doesn't complete (due to reboot, shutdown, process forced to end, etc.) TRIM will
> stay disabled until enabled using the Windows fsutil program (fsutil behavior
> set DisableDeleteNotify 0). If IFW completes the operation, even with errors
> reported, TRIM will be properly reset to the enabled state."
Re: TRIM
On Sun, 6 Jan 2013 13:00:09 PST, rseiler wrote:
>OK, could you maybe give a bit more background on this then? I don't quite see the connection between disabling TRIM and reducing IFW's caching. I understand why you'd want to minimize writes to SSD when possible, but how does temporarily disabling TRIM accomplish that?
>
>Does the absence of the option in IFD (DOS doesn't support TRIM) mean IFD avoids caching in DOS with SSDs? If it doesn't, would this suggest it's not the best idea to be using IFD (or IFL, apparently) for backing up SSDs?
>
>How much caching are we talking about (let's use the example of 30GB used on a 60GB SSD)?
If you search this forum for 'trim' you'll get some more background on
Trim and IFW, e.g.
http://www.terabyteunlimited.com/ucf/viewtopic.php?f=4&t=165&p=430&hilit=trim&sid=007b8a79719a06de3b7ef36335beba46#p430
(Search the internet for 'trim ssd' for details on what the Trim
command does).
Briefly, you only need to disable Trim in a multi-program environment
*and* when doing byte-for-byte verification.
The IFD and IFL systems will not be running any other programs at the
same time, therefore the problem will not arise.
With IFW, you *can* be running other programs simultaneously, which
can change the disk while the backup is running. (Windows itself can
change the HD.) If you have specified byte-for-byte verification and
windows has done some Trimming on the HD being imaged, the
verification can fail (although there is nothing wrong with the image
file).
Also, the buffer sizes needed for PhyLock will be larger because of
the extra changes to the HD from the Trim action. PhyLock is only
implemented with IFW because of the multi-program nature of Windows;
it is not needed for IFD/L.
>OK, could you maybe give a bit more background on this then? I don't quite see the connection between disabling TRIM and reducing IFW's caching. I understand why you'd want to minimize writes to SSD when possible, but how does temporarily disabling TRIM accomplish that?
>
>Does the absence of the option in IFD (DOS doesn't support TRIM) mean IFD avoids caching in DOS with SSDs? If it doesn't, would this suggest it's not the best idea to be using IFD (or IFL, apparently) for backing up SSDs?
>
>How much caching are we talking about (let's use the example of 30GB used on a 60GB SSD)?
If you search this forum for 'trim' you'll get some more background on
Trim and IFW, e.g.
http://www.terabyteunlimited.com/ucf/viewtopic.php?f=4&t=165&p=430&hilit=trim&sid=007b8a79719a06de3b7ef36335beba46#p430
(Search the internet for 'trim ssd' for details on what the Trim
command does).
Briefly, you only need to disable Trim in a multi-program environment
*and* when doing byte-for-byte verification.
The IFD and IFL systems will not be running any other programs at the
same time, therefore the problem will not arise.
With IFW, you *can* be running other programs simultaneously, which
can change the disk while the backup is running. (Windows itself can
change the HD.) If you have specified byte-for-byte verification and
windows has done some Trimming on the HD being imaged, the
verification can fail (although there is nothing wrong with the image
file).
Also, the buffer sizes needed for PhyLock will be larger because of
the extra changes to the HD from the Trim action. PhyLock is only
implemented with IFW because of the multi-program nature of Windows;
it is not needed for IFD/L.
Re: TRIM
Thanks for that, as I had missed that thread, but it alone left some questions that you answered.
I would think that the TRIM section of the manual should be expanded to more directly address why someone might want to use the option. Just saying that it reduces caching is not overly helpful.
TAC109 wrote:
>
> Briefly, you only need to disable Trim in a multi-program environment
> *and* when doing byte-for-byte verification.
>
> The IFD and IFL systems will not be running any other programs at the
> same time, therefore the problem will not arise.
>
> With IFW, you *can* be running other programs simultaneously, which
> can change the disk while the backup is running. (Windows itself can
> change the HD.) If you have specified byte-for-byte verification and
> windows has done some Trimming on the HD being imaged, the
> verification can fail (although there is nothing wrong with the image
> file).
>
> Also, the buffer sizes needed for PhyLock will be larger because of
> the extra changes to the HD from the Trim action. PhyLock is only
> implemented with IFW because of the multi-program nature of Windows;
> it is not needed for IFD/L.
I would think that the TRIM section of the manual should be expanded to more directly address why someone might want to use the option. Just saying that it reduces caching is not overly helpful.
TAC109 wrote:
>
> Briefly, you only need to disable Trim in a multi-program environment
> *and* when doing byte-for-byte verification.
>
> The IFD and IFL systems will not be running any other programs at the
> same time, therefore the problem will not arise.
>
> With IFW, you *can* be running other programs simultaneously, which
> can change the disk while the backup is running. (Windows itself can
> change the HD.) If you have specified byte-for-byte verification and
> windows has done some Trimming on the HD being imaged, the
> verification can fail (although there is nothing wrong with the image
> file).
>
> Also, the buffer sizes needed for PhyLock will be larger because of
> the extra changes to the HD from the Trim action. PhyLock is only
> implemented with IFW because of the multi-program nature of Windows;
> it is not needed for IFD/L.
Re: TRIM
On reading my reply again I realise I should have been using the
abbreviation 'SSD' rather than 'HD'.
I agree that the manual should be expanded by Terabyte to cover these
points.
On Mon, 7 Jan 2013 14:27:11 PST, rseiler wrote:
>Thanks for that, as I had missed that thread, but it alone left some questions that you answered.
>
>I would think that the TRIM section of the manual should be expanded to more directly address why someone might want to use the option. Just saying that it reduces caching is not overly helpful.
>
>TAC109 wrote:
>>
>> Briefly, you only need to disable Trim in a multi-program environment
>> *and* when doing byte-for-byte verification.
>>
>> The IFD and IFL systems will not be running any other programs at the
>> same time, therefore the problem will not arise.
>>
>> With IFW, you *can* be running other programs simultaneously, which
>> can change the disk while the backup is running. (Windows itself can
>> change the HD.) If you have specified byte-for-byte verification and
>> windows has done some Trimming on the HD being imaged, the
>> verification can fail (although there is nothing wrong with the image
>> file).
>>
>> Also, the buffer sizes needed for PhyLock will be larger because of
>> the extra changes to the HD from the Trim action. PhyLock is only
>> implemented with IFW because of the multi-program nature of Windows;
>> it is not needed for IFD/L.
>
abbreviation 'SSD' rather than 'HD'.
I agree that the manual should be expanded by Terabyte to cover these
points.
On Mon, 7 Jan 2013 14:27:11 PST, rseiler wrote:
>Thanks for that, as I had missed that thread, but it alone left some questions that you answered.
>
>I would think that the TRIM section of the manual should be expanded to more directly address why someone might want to use the option. Just saying that it reduces caching is not overly helpful.
>
>TAC109 wrote:
>>
>> Briefly, you only need to disable Trim in a multi-program environment
>> *and* when doing byte-for-byte verification.
>>
>> The IFD and IFL systems will not be running any other programs at the
>> same time, therefore the problem will not arise.
>>
>> With IFW, you *can* be running other programs simultaneously, which
>> can change the disk while the backup is running. (Windows itself can
>> change the HD.) If you have specified byte-for-byte verification and
>> windows has done some Trimming on the HD being imaged, the
>> verification can fail (although there is nothing wrong with the image
>> file).
>>
>> Also, the buffer sizes needed for PhyLock will be larger because of
>> the extra changes to the HD from the Trim action. PhyLock is only
>> implemented with IFW because of the multi-program nature of Windows;
>> it is not needed for IFD/L.
>
-
TeraByte Support
- Posts: 3625
- Joined: Thu May 05, 2011 10:37 pm
Re: TRIM
The byte-for-byte verification failures were before PHYLock cached the
TRIM'd sectors. But the second part is correct, when things get deleted
they are TRIMed which means the original contents need to be cached whereas
a normal delete doesn't overwrite all the data, just updates the directory
entry.
"Tom Cole" wrote in message news:4252@public.image...
Briefly, you only need to disable Trim in a multi-program environment
*and* when doing byte-for-byte verification.
Also, the buffer sizes needed for PhyLock will be larger because of
the extra changes to the HD from the Trim action. PhyLock is only
implemented with IFW because of the multi-program nature of Windows;
it is not needed for IFD/L.
TRIM'd sectors. But the second part is correct, when things get deleted
they are TRIMed which means the original contents need to be cached whereas
a normal delete doesn't overwrite all the data, just updates the directory
entry.
"Tom Cole" wrote in message news:4252@public.image...
Briefly, you only need to disable Trim in a multi-program environment
*and* when doing byte-for-byte verification.
Also, the buffer sizes needed for PhyLock will be larger because of
the extra changes to the HD from the Trim action. PhyLock is only
implemented with IFW because of the multi-program nature of Windows;
it is not needed for IFD/L.
Re: TRIM
Thanks for the clarification.
On Tue, 8 Jan 2013 01:23:50 PST, "TeraByte Support"
wrote:
>The byte-for-byte verification failures were before PHYLock cached the
>TRIM'd sectors. But the second part is correct, when things get deleted
>they are TRIMed which means the original contents need to be cached whereas
>a normal delete doesn't overwrite all the data, just updates the directory
>entry.
>
>"Tom Cole" wrote in message news:4252@public.image...
>
>Briefly, you only need to disable Trim in a multi-program environment
>*and* when doing byte-for-byte verification.
>
> Also, the buffer sizes needed for PhyLock will be larger because of
>the extra changes to the HD from the Trim action. PhyLock is only
>implemented with IFW because of the multi-program nature of Windows;
>it is not needed for IFD/L.
>
Re: TRIM
On Mon, 7 Jan 2013 14:27:11 PST, just as I was about to take a herb,
rseiler disturbed my reverie and wrote:
>I would think that the TRIM section of the manual should be expanded to more directly address why someone might want to use the option. Just saying that it reduces caching is not overly helpful.
Unfortunately, this is the general style of the TBU documentation. It
is otherwise well laid out and covers every option.
--
Cheers
DrT
______________________________
We may not be able to prevent the stormy times in
our lives; but we can always choose whether or not
to dance in the puddles (Jewish proverb).
rseiler disturbed my reverie and wrote:
>I would think that the TRIM section of the manual should be expanded to more directly address why someone might want to use the option. Just saying that it reduces caching is not overly helpful.
Unfortunately, this is the general style of the TBU documentation. It
is otherwise well laid out and covers every option.
--
Cheers
DrT
______________________________
We may not be able to prevent the stormy times in
our lives; but we can always choose whether or not
to dance in the puddles (Jewish proverb).