Icon that indicates a drive read or write operation?
Icon that indicates a drive read or write operation?
Might it be possible and practicable to design say, a taskbar icon which displays (or changes) when any drive reads and/or writes are occuring?
If this feature is not already available; it seems, to me, it could provide an indication of any actively illegal and unexpected external movement and it would warn a user not to try to implement wmpoweroff, wmreboot, restartwm or to unplug any flash stick or unmount a drive if any intended drive reads and/or writes are unfinished.
----------
Perhaps a desktop icon for those who hide their taskbar.
If this feature is not already available; it seems, to me, it could provide an indication of any actively illegal and unexpected external movement and it would warn a user not to try to implement wmpoweroff, wmreboot, restartwm or to unplug any flash stick or unmount a drive if any intended drive reads and/or writes are unfinished.
----------
Perhaps a desktop icon for those who hide their taskbar.
Hi tallboy, greengeek, et al,
A red light on my desktop tower flashes at regular intervals of about six seconds. I have read that that flashing shows some kind of hard drive activity, but I have not personally seen a detailed explanation of exactly what is, or could be, happening.
I always use a Multi-session-live-CD/DVD (as do you, tallboy) and a mounted flash stick (or sometimes two mounted flash sticks when backing-up).
Apart from the flash stick(s) it is rare for any other drive or partition to be deliberately accessed/mounted after boot-up.
This thread had its origins in my wondering if the commands wmpoweroff, wmreboot or restartwm would be automatically delayed whilst awaiting the finish of an active drive read/write operation (e.g, download or back-up). After a simple single-case test it seemed unlikely that a delay would be implemented by any of those three commands - then I also wondered about unauthorised fraudulent/stealth communication initiated by any unknown external party.
I could remove (or perhaps disable) my hard drive(s) and my Multi-session option would still work - but I have no idea if my tower light would then stop flashing. My flash sticks’ lights are out of view behind me - so a taskbar read/write warning icon would suit me ideally - but an expert opinion if that may be possible and practicable was the limit of my enquiry.
My regards
Updqte:
I have now emboldened my above conjecture - because with the benefit of helpful responses below:
that conjecture about how the poweroff and reboot commands operate was at best only partially right, but more than likely - totally wrong.
A red light on my desktop tower flashes at regular intervals of about six seconds. I have read that that flashing shows some kind of hard drive activity, but I have not personally seen a detailed explanation of exactly what is, or could be, happening.
I always use a Multi-session-live-CD/DVD (as do you, tallboy) and a mounted flash stick (or sometimes two mounted flash sticks when backing-up).
Apart from the flash stick(s) it is rare for any other drive or partition to be deliberately accessed/mounted after boot-up.
This thread had its origins in my wondering if the commands wmpoweroff, wmreboot or restartwm would be automatically delayed whilst awaiting the finish of an active drive read/write operation (e.g, download or back-up). After a simple single-case test it seemed unlikely that a delay would be implemented by any of those three commands - then I also wondered about unauthorised fraudulent/stealth communication initiated by any unknown external party.
I could remove (or perhaps disable) my hard drive(s) and my Multi-session option would still work - but I have no idea if my tower light would then stop flashing. My flash sticks’ lights are out of view behind me - so a taskbar read/write warning icon would suit me ideally - but an expert opinion if that may be possible and practicable was the limit of my enquiry.
My regards
Updqte:
I have now emboldened my above conjecture - because with the benefit of helpful responses below:
that conjecture about how the poweroff and reboot commands operate was at best only partially right, but more than likely - totally wrong.
Last edited by Jasper on Thu 11 Jul 2013, 13:59, edited 1 time in total.
Hmm, I would think that I/O control for Linux devices may be possible to monitor, and I had an idea about looking for the source of the properties for one of my frequently used USB sticks (one of them actually collapsed today, RIP), but that was not very enlightening...
I think there are so many kernel related I/O operations going on between devices, that monitoring what we normally think of as reading and writing to a device may be difficult to separate from for example a monitoring function. An example may be the HDD light going on every six seconds; there is probably some exchange of info between different devices, how can that be separated from other read/write operations?
tallboy
BTW, I have often seen that a save to a USB stick will not be done right away, sometimes the writing process don't start until I unmount the stick, so there is also a possible delay to take into consideration.
I think there are so many kernel related I/O operations going on between devices, that monitoring what we normally think of as reading and writing to a device may be difficult to separate from for example a monitoring function. An example may be the HDD light going on every six seconds; there is probably some exchange of info between different devices, how can that be separated from other read/write operations?
tallboy
BTW, I have often seen that a save to a USB stick will not be done right away, sometimes the writing process don't start until I unmount the stick, so there is also a possible delay to take into consideration.
- Attachments
-
- properties.png
- (12.72 KiB) Downloaded 456 times
True freedom is a live Puppy on a multisession CD/DVD.
There is a currently used technology used by differing OSes (Windows/Macs/Linuxes) that was developed years ago by IBM in conjunction with a (I believe) Stanford University Math Professor in queuing theory. That technology became known internally as "Lazy-write".
What it refers to is the ability of the use of system buffers to more efficiently dump information to a device versus writing each time an app sends data to the I/O subsystem. It is deemed to be better utilization on both the system and the HDD devices.
Developers and administrators in the Linux world understand this system design and frequently will make use of the sync command to flush buffers out to the target device rather than wait for some normal system operations to handle this data movement. There are other varied reasons when this technique will be used, as well. Similar things are done as well by the other OSes.
This happens in the background, for the most part, and users almost never see this or notice this activity. And, on some very rare occasions (like unexpected power loss) will a HDD/USB be left with some tidy up operations that need be done on system reboots.
Hope this helps
What it refers to is the ability of the use of system buffers to more efficiently dump information to a device versus writing each time an app sends data to the I/O subsystem. It is deemed to be better utilization on both the system and the HDD devices.
Developers and administrators in the Linux world understand this system design and frequently will make use of the sync command to flush buffers out to the target device rather than wait for some normal system operations to handle this data movement. There are other varied reasons when this technique will be used, as well. Similar things are done as well by the other OSes.
This happens in the background, for the most part, and users almost never see this or notice this activity. And, on some very rare occasions (like unexpected power loss) will a HDD/USB be left with some tidy up operations that need be done on system reboots.
Hope this helps
Hi amigo et al,
Thank you all for your comments. However, I do not fully understand the sync command and would appreciate elaboration,
I follow that the buffers already in RAM are written to disk, but what if I'm near the start of a copy and paste where the data to be copied is hugely larger than my RAM - so presumably most of that data is not yet buffered.
Does sync queue a subsequent poweroffwm (or rebootwm) until all the data intended to be copied is actually pasted?
My regards
Thank you all for your comments. However, I do not fully understand the sync command and would appreciate elaboration,
I follow that the buffers already in RAM are written to disk, but what if I'm near the start of a copy and paste where the data to be copied is hugely larger than my RAM - so presumably most of that data is not yet buffered.
Does sync queue a subsequent poweroffwm (or rebootwm) until all the data intended to be copied is actually pasted?
My regards
- RetroTechGuy
- Posts: 2947
- Joined: Tue 15 Dec 2009, 17:20
- Location: USA
In Linux, data often resides in memory and is not written to the HDD. This is particularly true in Puppy, where the writes are limited to prevent wearing out the USB flash media.Jasper wrote:Hi amigo et al,
Thank you all for your comments. However, I do not fully understand the sync command and would appreciate elaboration,
I follow that the buffers already in RAM are written to disk, but what if I'm near the start of a copy and paste where the data to be copied is hugely larger than my RAM - so presumably most of data is not yet buffered.
Does sync queue a subsequent poweroffwm (or rebootwm) until all the data intended to be copied is actually pasted?
My regards
A "sync" command tells the system to stop storing that data in RAM, and write the data to the HDD (or flash drive). That memory is then released (and the data resides only on the HDD).
I believe that if your data copy is larger than RAM, it will typically just be stored in swap (virtual RAM), until physically flushed onto the HDD.
[url=http://murga-linux.com/puppy/viewtopic.php?t=58615]Add swapfile[/url]
[url=http://wellminded.net63.net/]WellMinded Search[/url]
[url=http://puppylinux.us/psearch.html]PuppyLinux.US Search[/url]
[url=http://wellminded.net63.net/]WellMinded Search[/url]
[url=http://puppylinux.us/psearch.html]PuppyLinux.US Search[/url]
In my experience the reboot or poweroff will not proceed until the data is finished being copied to the usb disk (I cant say if the behaviour is the same with copying to a HDD).Jasper wrote:Does sync queue a subsequent poweroffwm (or rebootwm) until all the data intended to be copied is actually pasted?
This is particularly noticeable with any usb stick that has a slow write speed. My suggestion is to use a cheap/slow 16GB usb stick, fit it to a usb 1.1 port, queue up 10 Puppy isos to be copied to it, then select poweroff and see what happens (try to find a usb stick that has an LED so you have a better idea what is happening...)
HI greengeek,
I tried a very similar flash stick test to the test you suggested in your post immediately above.
Thank you for the idea and I'm very pleased to report that my experience was identical to yours.
My regards
It seems my conjecture about how the poweroff and reboot commands operate was at best only partially right, but more than likely - totally wrong.
Also, thanks again to all responders.
I tried a very similar flash stick test to the test you suggested in your post immediately above.
Thank you for the idea and I'm very pleased to report that my experience was identical to yours.
My regards
It seems my conjecture about how the poweroff and reboot commands operate was at best only partially right, but more than likely - totally wrong.
Also, thanks again to all responders.
I have had problems in the past when copying large volumes of data to usb sticks that do not have an LED - at least once I have thought that the PC was hung, and pulled the stick out before the data transfer was complete. For that reason I like your original idea of having an on-screen icon that indicates that data transfer (or savefile updates) are incomplete and still queued or still active.
(Maybe also a "pupsave interval countdown timer indicator"?)
(Maybe also a "pupsave interval countdown timer indicator"?)
I have compiled xosview with only enabling the diskmeter .
dependencies are :
bash-3.00# ldd ./xosview-1.8.3-diskmeter-dyn
Homepages :
- 1.8.3 : http://sourceforge.net/projects/xosview/files/
+1.9.0 : http://www.pogo.org.uk/~mark/xosview/releases/
I have chosen the old version, because the ./configure script has been dropped since version 1.9.x
Play around with it. If it works, drop it into /root/Startup or create a tray icon to launch it .
dependencies are :
bash-3.00# ldd ./xosview-1.8.3-diskmeter-dyn
- linux-gate.so.1 => (0xffffe000)
libXpm.so.4 => /usr/X11R7/lib/libXpm.so.4 (0xb7fab000)
libX11.so.6 => /usr/X11R7/lib/libX11.so.6 (0xb7eda000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7df0000)
libm.so.6 => /lib/libm.so.6 (0xb7dce000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb7dc3000)
libc.so.6 => /lib/libc.so.6 (0xb7cc8000)
libXau.so.6 => /usr/X11R7/lib/libXau.so.6 (0xb7cc5000)
libXdmcp.so.6 => /usr/X11R7/lib/libXdmcp.so.6 (0xb7cc0000)
libdl.so.2 => /lib/libdl.so.2 (0xb7cbc000)
/lib/ld-linux.so.2 (0xb7fb9000)
Homepages :
- 1.8.3 : http://sourceforge.net/projects/xosview/files/
+1.9.0 : http://www.pogo.org.uk/~mark/xosview/releases/
I have chosen the old version, because the ./configure script has been dropped since version 1.9.x
Play around with it. If it works, drop it into /root/Startup or create a tray icon to launch it .
- Attachments
-
- xosview_diskmeter.jpg
- (6.51 KiB) Downloaded 284 times
-
- xosview-1.8.3-diskmeter-dyn.bz2
- (73.36 KiB) Downloaded 392 times
Hi again Karl,
After more extensive testing - your app definitely suits my own needs perfectly.
I added your app to my JWM Menu > Desktop > KGon [as the menu name].
I also tried the icon below (with your initials) which I put in /usr/local/lib/X11/mini-icons for the dual purpose of using it as my JWM menu icon and as the app/taskbar icon.
However, my eyesight is failing and I couldn't read your initials; so I settled on the other icon with the yellow plus sign.
---------------------
I have some minor suggestions in case you may like to consider them together with any of your own tweaks or other ideas posted by say, 31st July:
* perhaps make "read/write" red with " idle" remaining green [but space instead of /].
* perhaps make the graphing in your green bar red instead of blue.
* perhaps have the "zero" show in green with other numbers in red.
* perhaps sound a bark when finished.
* perhaps incorporate your own choice of icon directly into your app.
My regards and thanks
After more extensive testing - your app definitely suits my own needs perfectly.
I added your app to my JWM Menu > Desktop > KGon [as the menu name].
I also tried the icon below (with your initials) which I put in /usr/local/lib/X11/mini-icons for the dual purpose of using it as my JWM menu icon and as the app/taskbar icon.
However, my eyesight is failing and I couldn't read your initials; so I settled on the other icon with the yellow plus sign.
---------------------
I have some minor suggestions in case you may like to consider them together with any of your own tweaks or other ideas posted by say, 31st July:
* perhaps make "read/write" red with " idle" remaining green [but space instead of /].
* perhaps make the graphing in your green bar red instead of blue.
* perhaps have the "zero" show in green with other numbers in red.
* perhaps sound a bark when finished.
* perhaps incorporate your own choice of icon directly into your app.
My regards and thanks
- Attachments
-
- screenshot.jpg
- (13.56 KiB) Downloaded 262 times
-
- xosview.jpg
- (1.92 KiB) Downloaded 260 times
-
- xosview.png
- (2.05 KiB) Downloaded 265 times
Thanks KarlKarl Godt wrote:I have compiled xosview with only enabling the diskmeter .
Will be invaluable for my Acer AO 722...which has no HDD LED indicator at all!!
@Jasper: check out http://linux.die.net/man/1/xosview
There are some options you may find useful, e.g.:
Code: Select all
./xosview-1.8.3-diskmeter-dyn -xrm "xosview*diskReadColor: green" -xrm "xosview*diskWriteColor: red" -xrm "xosview*diskIdleColor: gray"
- Attachments
-
- Screenshot.png
- (4.86 KiB) Downloaded 497 times
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
Hi Jasper !
Glad you like it !
I know of xosview since Suse6.2 on 133MHz P-I .
The source is horrible to read and understand , but mostly works .
I can understand people preferring the conky monitor .
I like it because I can resize and place the window wherever I want .
I don't use conky at all .
I had started to compile it in late 2010 , mainly focusing on the lmstemp meter with PATH to different files in /sys for the it87 temperature module for my boards from 2000/2001 back then and now for the coretemp temperature module to be able to monitor the CPU temperature if not somewhere in /proc/acpi available and not to exit if not found .
Xosview sources the /root/.Xdefaults file , that could have a part that could look like
Some of the variables seem not to be used eg .: xosview*diskUsedColor
That below are the two sections of the Xdefaults file used while compiling to set default values (not changed any values but False for all other meters) :
to have a comparison .
That's it so far for color preferences .
An intensive manpage can be found here : http://linux.die.net/man/1/xosview
SFR was faster ..
With your color scheme as I understand it , mine full-featured looks like this :
Glad you like it !
I know of xosview since Suse6.2 on 133MHz P-I .
The source is horrible to read and understand , but mostly works .
I can understand people preferring the conky monitor .
I like it because I can resize and place the window wherever I want .
I don't use conky at all .
I had started to compile it in late 2010 , mainly focusing on the lmstemp meter with PATH to different files in /sys for the it87 temperature module for my boards from 2000/2001 back then and now for the coretemp temperature module to be able to monitor the CPU temperature if not somewhere in /proc/acpi available and not to exit if not found .
Xosview sources the /root/.Xdefaults file , that could have a part that could look like
Code: Select all
! XOsview settings begin
! General Resources
!xosview*title:
!xosview*geometry: +5+5
!xosview*display:
xosview*captions: True
xosview*labels: True
xosview*transparent: False
xosview*meterLabelColor: wheat
xosview*usedlabels: True
xosview*usedLabelColor: wheat
xosview*borderwidth: 0
xosview*font: 7x13
xosview*background: #34A56C
xosview*foreground: wheat
xosview*enableStipple: False ! Change to true to try beta stipple support.
xosview*samplesPerSec: 10 ! not yet supported
xosview*graphNumCols: 128 ! number of samples shown in a graph
! Disk Meter Resources
xosview*disk: True
xosview*diskUsedColor: seagreen
xosview*diskIdleColor: #8FFF00
!some kind of lightgreen
xosview*diskWriteColor: #FF0000
!some kind of read
xosview*diskReadColor: #F9983C
!some kind of orange
xosview*diskBandwidth: 100000000 ! 100MB/s should be reasonable today for
! both IDE and SCSI
xosview*diskPriority: 10
xosview*diskDecay: True
xosview*diskUsedFormat: autoscale
xosview*diskGraph: True
! XOsview settings end
That below are the two sections of the Xdefaults file used while compiling to set default values (not changed any values but False for all other meters) :
Code: Select all
! General Resources
!xosview*title:
!xosview*geometry: +5+5
!xosview*display:
xosview*captions: True
xosview*labels: True
xosview*transparent: False
xosview*meterLabelColor: wheat
xosview*usedlabels: True
xosview*usedLabelColor: wheat
xosview*borderwidth: 0
xosview*font: 7x13
xosview*background: navy
xosview*foreground: wheat
xosview*enableStipple: False ! Change to true to try beta stipple support.
xosview*samplesPerSec: 10 ! not yet supported
xosview*graphNumCols: 128 ! number of samples shown in a graph
! Disk Meter Resources
xosview*disk: True
xosview*diskUsedColor: seagreen
xosview*diskIdleColor: aquamarine
xosview*diskWriteColor: SlateBlue1
xosview*diskReadColor: SkyBlue
xosview*diskBandwidth: 10000000 ! 10MB/s should be reasonable today for
! both IDE and SCSI
xosview*diskPriority: 10
xosview*diskDecay: True
xosview*diskUsedFormat: autoscale
xosview*diskGraph: True
That's it so far for color preferences .
An intensive manpage can be found here : http://linux.die.net/man/1/xosview
SFR was faster ..
With your color scheme as I understand it , mine full-featured looks like this :
- Attachments
-
- xosview-full.jpg
- (37.38 KiB) Downloaded 471 times
«Give me GUI or Death» -- I give you [[Xx]term[inal]] [[Cc]on[s][ole]] .
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P
Depending on which puppy you run, you may also take a look at xosview from Ubuntu and Debian repos. There are several similar packages, like wmcpu, in Debian.
There is also iotop, which present a list, like top.
tallboy
There is also iotop, which present a list, like top.
tallboy
True freedom is a live Puppy on a multisession CD/DVD.
xosview-1.14
Code: Select all
! xosview resources (override into your .Xdefaults file)
! General Resources
xosview*title: Xosview DiskMeter
xosview*geometry: 220x40
!xosview*display: 220x40
xosview*captions: True
xosview*labels: True
xosview*meterLabelColor: cyan
xosview*usedlabels: True
xosview*usedLabelColor: wheat
xosview*borderwidth: 1
xosview*font: 7x13
xosview*background: seagreen
! navy
xosview*foreground: yellow
xosview*enableStipple: False ! Change to true to try beta stipple support.
xosview*samplesPerSec: 5
xosview*graphNumCols: 135 ! number of samples shown in a graph
! Disk Meter Resources
xosview*disk: True
xosview*diskUsedColor: yellow
xosview*diskIdleColor: LightGreen
xosview*diskWriteColor: DarkRed
xosview*diskReadColor: orange2
xosview*diskBandwidth: 100000000 ! 100MB/s
xosview*diskPriority: 10
xosview*diskDecay: True
xosview*diskUsedFormat: autoscale
xosview*diskGraph: True
Code: Select all
// MeterMaker.cc
// Copyright (c) 1994, 1995, 2002, 2006 by Mike Romberg ( mike.romberg@noaa.gov )
//
// This file may be distributed under terms of the GPL
//
#include "MeterMaker.h"
#include "xosview.h"
#include <fstream>
#include "diskmeter.h"
#include <stdlib.h>
#include <sstream>
#include <iomanip>
using namespace std;
MeterMaker::MeterMaker(XOSView *xos){
_xos = xos;
}
void MeterMaker::makeMeters(void){
if (_xos->isResourceTrue("disk"))
push(new DiskMeter(_xos, atof(_xos->getResource("diskBandwidth"))));
}
Code: Select all
#Makefile
-include .config
AWK ?= awk
INSTALL ?= install
PLATFORM ?= linux
# Installation paths
PREFIX ?= /usr/local
BINDIR ?= $(PREFIX)/bin
MANDIR ?= $(PREFIX)/share/man
# Optional build arguments; user may wish to override
OPTFLAGS ?= -Wall -Os
# Required build arguments
CPPFLAGS += $(OPTFLAGS) -I. -MMD
LDLIBS += -lX11
LDFLAGS += -s
OBJS = Host.o \
Xrm.o \
bitfieldmeter.o \
bitmeter.o \
defaultstring.o \
fieldmeter.o \
fieldmeterdecay.o \
fieldmetergraph.o \
llist.o \
main.o \
meter.o \
xosview.o \
xwin.o
# Optional platform type
ifeq ($(PLATFORM), linux)
OBJS += linux/MeterMaker.o \
linux/diskmeter.o
CPPFLAGS += -Ilinux/
endif
DEPS := $(OBJS:.o=.d)
xosview: $(OBJS)
$(CXX) $(LDFLAGS) -o $@ $^ $(LDLIBS)
defaultstring.cc: Xdefaults defresources.awk
$(AWK) -f defresources.awk Xdefaults > defaultstring.cc
Xrm.o: CXXFLAGS += -Wno-write-strings
.PHONY: dist install clean
dist:
./mkdist $(VERSION)
install: xosview
$(INSTALL) -d $(DESTDIR)$(BINDIR)
$(INSTALL) -d $(DESTDIR)$(MANDIR)/man1
$(INSTALL) -m 755 xosview $(DESTDIR)$(BINDIR)/xosview
$(INSTALL) -m 644 xosview.1 $(DESTDIR)$(MANDIR)/man1/xosview.1
clean:
rm -f xosview $(OBJS) $(DEPS) defaultstring.cc
-include $(DEPS)
Precise-5.5 with Precise-5.7.1 devx
# ldd ./xosview
- linux-gate.so.1 => (0xffffe000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7693000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xb75ae000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb758f000)
libc.so.6 => /lib/libc.so.6 (0xb73e5000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb73c4000)
libdl.so.2 => /lib/libdl.so.2 (0xb73bf000)
libm.so.6 => /lib/libm.so.6 (0xb7393000)
/lib/ld-linux.so.2 (0xb77c9000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb738e000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7387000)
76 ./xosview , stripped
-static gave libX11.a errors - Ubuntu seems to cook only with water , too .
# /lib/libc.so.6
GNU C Library (Ubuntu EGLIBC 2.15-0ubuntu10.3) stable release version 2.15, by Roland McGrath et al.
- Attachments
-
- xosview-1.14_diskmeteronly.bz2
- (30.92 KiB) Downloaded 300 times