On Sat, 2023-04-15 at 21:59 +0100, Andy Pieters wrote:
> The size of the capacitor you need to hold that charge is quite small.
Hi,
maybe I'm mistaken. If the capacitors are able to provide enough energy,
then I still suspect a reset when powering an USB stick off and on
again. It's unlikely that
Hi,
Regarding cutting power to the USB stick, as well as physically pulling
it out, it may be possible to ‘turn it off and on again’ by software.
https://www.kernel.org/doc/html/v4.16/driver-api/usb/power-management.html#usb-port-power-control
https://github.com/mvp/uhubctl#readme
On Sat, 15 Apr 2023 at 21:17, Ralf Mardorf wrote:
> On Sat, 2023-04-15 at 12:47 +0100, Ralph Corderoy wrote:
> > Could it have a store of power, e.g. capacitor, which takes a while to
> > discharge. :-)
>
> No! An electrolytic capacitor that holds enough charge, is way larger
> than an USB stick
On Sat, 2023-04-15 at 12:47 +0100, Ralph Corderoy wrote:
> Could it have a store of power, e.g. capacitor, which takes a while to
> discharge. :-)
No! An electrolytic capacitor that holds enough charge, is way larger
than an USB stick.
When I was still working as a developer for recording studio
Hi u34,
> Isn't it better to also turn the USB stick power off and on?
> The stick could have its own, builtin, cache. Doesn't it? Perhaps it
> is, too, reading from its cache, not from its permanent storage?
True.
Could it have a store of power, e.g. capacitor, which takes a while to
discharg
Ralph Corderoy wrote:
> Hi Ralf,
>
> > I want to check the integrity of USB transferred, saved files by using
> > a tool, without manually clearing cached data manually.
>
> Why do you want to avoid manually clearing the cache?
>
> The problem with clearing the cache is it is the cache for eve
Hi Ralf,
> I want to check the integrity of USB transferred, saved files by using
> a tool, without manually clearing cached data manually.
Why do you want to avoid manually clearing the cache?
The problem with clearing the cache is it is the cache for every device.
It is better to simply umount
On Fri, 2023-04-14 at 17:34 -0400, Genes Lists wrote:
> And no, its not 'stale' data, blocks that have not changed are fetched
> from buffer cache.
Hi,
the kernel only knows access via software, it cannot know when something
will break in the hardware without any feedback. If a nano thing in an
Ralf Mardorf wrote:
> Hi,
>
> my google search was "does linux diff compare data using a cache".
>
> I'm trying to figure out what's going on. The first diff of 10 GiB of
> data copied from a SATA3 SSD to an USB 2 stick connected to an USB 3
> port took around a minute, right after the copy fin
On Fri, Apr 14, 2023 at 10:59:13PM +0200, Ralf Mardorf wrote:
Hi Ralf,
> Hi,
>
> my google search was "does linux diff compare data using a cache".
>
> I'm trying to figure out what's going on. The first diff of 10 GiB of
> data copied from a SATA3 SSD to an USB 2 stick connected to an USB 3
>
On 4/14/23 16:59, Ralf Mardorf wrote:
Hi,
my google search was "does linux diff compare data using a cache".
Its not "diff" doing anything weird, its simply the linux kernel buffer
cache - and it works great doesn't it.
And no, its not 'stale' data, blocks that have not changed are fetched
try bsdiff maybe? https://www.daemonology.net/bsdiff/
it will probably be very slow if you're not going through the filesystem
cache
On Fri, Apr 14, 2023, 4:59 PM Ralf Mardorf wrote:
> Hi,
>
> my google search was "does linux diff compare data using a cache".
>
> I'm trying to figure out what's
Hi,
my google search was "does linux diff compare data using a cache".
I'm trying to figure out what's going on. The first diff of 10 GiB of
data copied from a SATA3 SSD to an USB 2 stick connected to an USB 3
port took around a minute, right after the copy finished. A second diff
needed 3 second
13 matches
Mail list logo
