On Fri 13 Sep 2024 at 15:00:14 (+0300), Anssi Saari wrote:
> David Wright writes:
> > On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:
>
> >> Why do you think that? Which part of the fsync manpage explicitly covers
> >> fsync's effect on device files? Share share, it's fair.
>
> > “fs
On Mon, Sep 16, 2024 at 01:12:35PM +0300, Anssi Saari wrote:
Michael Stone writes:
[1] insofar as you want to use dd at all ...
dd does conveniently provide progress and stats whereas cp does not.
stats which are misleading without the proper arguments, so it's a bit
of a wash. This is ac
On Mon, Sep 16, 2024 at 11:15:50AM +0200, to...@tuxteam.de wrote:
Actually, dd doesn't "do" file system cache (unless you are dd'ing
to a file, of course).
Incorrect; linux block device accesses cache unless specifically asked
not to. This is very easy to demonstrate: run something like "dd
i
On Mon, Sep 16, 2024 at 01:40:52PM +0300, Anssi Saari wrote:
> writes:
[...]
> > You are talking device cache. Jeffrey is talking file system cache.
> > Two different (and independent) layers.
>
> I think Jeffrey's post was pretty clear in that it was not about writing
> to a file system. Notwi
writes:
> On Mon, Sep 16, 2024 at 12:00:53PM +0300, Anssi Saari wrote:
>> Jeffrey Walton writes:
>>
>> > The file system cache is still holding the writes. If I remove the
>> > SDcard and try to use it, the image is corrupt. When I say "remove", I
>> > mean pop the card out of the card reader s
Michael Stone writes:
> [1] insofar as you want to use dd at all ...
dd does conveniently provide progress and stats whereas cp does not.
On Mon, Sep 16, 2024 at 12:00:53PM +0300, Anssi Saari wrote:
> Jeffrey Walton writes:
>
> > The file system cache is still holding the writes. If I remove the
> > SDcard and try to use it, the image is corrupt. When I say "remove", I
> > mean pop the card out of the card reader since the write ha
Jeffrey Walton writes:
> The file system cache is still holding the writes. If I remove the
> SDcard and try to use it, the image is corrupt. When I say "remove", I
> mean pop the card out of the card reader since the write has
> supposedly finished.
All right. So in fact, block devices either h
On Sun, Sep 15, 2024 at 10:47:46PM -0400, Michael Stone wrote:
> On Fri, Sep 13, 2024 at 08:33:55PM +0200, to...@tuxteam.de wrote:
[rough dd test]
> It's an invalid test because you hit the end of the device; there's nothing
> left to sync.
This doesn't make sense to me. The question was whether
On Sun, Sep 08, 2024 at 10:59:58AM -0700, David Christensen wrote:
2. Using dd(1) with sync(1):
3. Using dd(1) without explicit synchronization:
These two tests are identical, as dd has exited (and all the performance
information has been printed) before sync runs. The flag you want[1] is
con
On Fri, Sep 13, 2024 at 08:33:55PM +0200, to...@tuxteam.de wrote:
tomas@caliban:~$ time sudo dd if=/dev/zero of=/dev/sdb bs=1M ; time sync
dd: error writing '/dev/sdb': No space left on device
15268+0 records in
15267+0 records out
16008609792 bytes (16 GB, 15 GiB) copied, 3614.25 s, 4.4 MB/
On 9/13/24 12:06, Jeffrey Walton wrote:
To add a datapoint...
My daily driver workstation is really fast with lots of RAM. It has
3.4 GHz cpu and 64 GB of RAM. I also set swappiness to a low value
to avoid spilling out of RAM.
I use a lot of SBC's/dev boards for testing. They usually use a
S
On Fri, Sep 13, 2024, at 5:00 AM, Anssi Saari wrote:
...
> So the answer to
> the question "is running sync needed after dd to block device" is
> no. Someone else posted that too on this list recently, in another
> thread.
On the other hand, it may not be necessary, but it doesn't do any harm.
On Fri, Sep 13, 2024 at 8:00 AM Anssi Saari
wrote:
>
> David Wright writes:
>
> > On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:
>
> >> Why do you think that? Which part of the fsync manpage explicitly covers
> >> fsync's effect on device files? Share share, it's fair.
>
> > “fsync()
On Fri, Sep 13, 2024 at 03:00:14PM +0300, Anssi Saari wrote:
> David Wright writes:
>
> > On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:
>
> >> Why do you think that? Which part of the fsync manpage explicitly covers
> >> fsync's effect on device files? Share share, it's fair.
>
> >
David Wright writes:
> On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:
>> Why do you think that? Which part of the fsync manpage explicitly covers
>> fsync's effect on device files? Share share, it's fair.
> “fsync() transfers ("flushes") all modified in-core data of (i.e.,
> modi
On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:
> David Wright writes:
> > On Mon 09 Sep 2024 at 11:52:19 (+0300), Anssi Saari wrote:
> >> David Christensen writes:
> >>
> >> > 2. sync(1) is unnecessary.
> >>
> >> Does it even do anything wrt device files? sync(2) says "sync() cause
David Wright writes:
> On Mon 09 Sep 2024 at 11:52:19 (+0300), Anssi Saari wrote:
>> David Christensen writes:
>>
>> > 2. sync(1) is unnecessary.
>>
>> Does it even do anything wrt device files? sync(2) says "sync() causes
>> all pending modifications to filesystem metadata and cached file da
On Mon 09 Sep 2024 at 11:52:19 (+0300), Anssi Saari wrote:
> David Christensen writes:
>
> > 2. sync(1) is unnecessary.
>
> Does it even do anything wrt device files? sync(2) says "sync() causes
> all pending modifications to filesystem metadata and cached file data to
> be written to the under
David Christensen writes:
> 2. sync(1) is unnecessary.
Does it even do anything wrt device files? sync(2) says "sync() causes
all pending modifications to filesystem metadata and cached file data to
be written to the underlying filesystems."
debian-user:
I had the need to zero-fill a Seagate Constellation ES.2 3 TB SATA
magnetic hard disk drive using an Intel DQ67SW motherboard, Intel Core
i7-2600S processor, 8 GB dual-channel memory, StarTech PEXSAT32 adapter,
and Debian:
2024-09-08 08:05:02 root@bullseye-bios
~/hardware/seaga
21 matches
Mail list logo
