Francois117
Posts: 11
Joined: Thu Apr 07, 2016 11:26 pm

filesystem write files - after reboot the old data is back

Fri Apr 08, 2016 6:41 am

Okay this is a really weird problem occurring on two raspberry pi systems with their respective 8GB SD memory cards:

Simple example: When I write files to the disk, it looks like the files are written.
I can edit a file vim test.dat, enter text into it, save.

Code: Select all

ll
will list the file.

Code: Select all

cat
will show the contents of the file. After a reboot the file will be gone.

So what I think is happening is that ubuntu writes the files to ubuntu's disk cache but it doesn't commit the files to disk. The userspace programs can continue reading the files and using them, but the cache returns the directory listings and file contents from ram, and not from the disk. Because after a reboot the disk has none of the new data.

Another example:

Code: Select all

dd if=/dev/zero of=testfile.dat bs=1M count=1000
It creates a file with 1GB size. ll lists the file.

Code: Select all

 df -h
shows that 1GB more has been used by the data on disk. But after a reboot the file is gone and df -h shows the old available space.

Fun fact: I know the SD card's max writing speed is 9MB/sec, which is what I get when I dd the disk image onto it using my laptop. But running this dd command on the SD card in the raspberry, dd reports the write speed as 110MB/sec. Impossible. This is why I think the operating system is just writing to RAM and not committing to disk.

Third example: I have a script that edits a file named interfaces, and then copies it, as root, over the /etc/network/interfaces file, to change the IP of the device. Then the script reboots.

Code: Select all

#!/bin/bash
cp /var/project/scripts/interfaces /etc/network/interfaces
/sbin/reboot
After the reboot, the device is still on its old IP address... Weird...

Fourth example: The raspberry runs a percona mySQL database. I have a table that contains 186 entries. I truncate the table. Look at the data using the php code and also using webmin - the table is empty like it should be. After a reboot the data is back. Really... 186 entries. This is freaking me out.

I can be completely wrong. Any ideas?

When I realised the files are not written to the SD card, the first thing I suspected was that the SD card is faulty. So I switched on another raspberry running an older version of the ubuntu installation on its own SD card and it exhibited exactly the same issue!

I have been working on this ubuntu 14.04 installation and making periodic backups by cloning the disk image after every major sofware update. I have been noticing strange things (like the IP not changing after running my script) but I did not realise this problem until today, it seems like all the cloned disk images I have exhibit this issue. It must have worked fine up to a point and then something went wrong with ubuntu on the pi...

Question: What can I do to get ubuntu to write to the SD card?

I installed Ubuntu from this page:
https://wiki.ubuntu.com/ARM/RaspberryPi

Heater
Posts: 13924
Joined: Tue Jul 17, 2012 3:02 pm

Re: filesystem write files - after reboot the old data is ba

Fri Apr 08, 2016 12:24 pm

How are you shutting down your Pi. Simply yank the power can cause loss of data that has only made it the disk buffers.
Memory in C++ is a leaky abstraction .

Francois117
Posts: 11
Joined: Thu Apr 07, 2016 11:26 pm

Re: filesystem write files - after reboot the old data is ba

Fri Apr 08, 2016 1:44 pm

Thanks for the reply, Heater.

I have yanked the power many times. Out in the field, the system must be able to deal with power failures. It has caused no problems in the past, and he question of whether it caused the current state is debatable.

The current state seems to have occurred on multiple devices using multiple SD cards at more or less the same time. That's why I doubt it was caused by yanking the power.

Currently, I can write to files (text files, database files or whatever as shown above) and it looks like the files are being saved, but after a reboot the new files or new data in files is gone. And with "reboot" I mean "sudo reboot". It's not even a power cycle.

Frustrating.

edo1
Posts: 136
Joined: Sun Jun 15, 2014 3:33 pm
Location: Russia

Re: filesystem write files - after reboot the old data is ba

Fri Apr 08, 2016 2:30 pm

could you show output of these commands:

Code: Select all

df -h

Code: Select all

mount
?

Francois117
Posts: 11
Joined: Thu Apr 07, 2016 11:26 pm

Re: filesystem write files - after reboot the old data is ba

Fri Apr 08, 2016 4:30 pm

Code: Select all

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2  7,2G  2,3G  4,7G  33% /
devtmpfs        458M  4,0K  458M   1% /dev
none            4,0K     0  4,0K   0% /sys/fs/cgroup
none             93M  312K   93M   1% /run
none            5,0M     0  5,0M   0% /run/lock
none            462M     0  462M   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/mmcblk0p1   64M   20M   45M  31% /boot/firmware

mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
devtmpfs on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
/dev/mmcblk0p1 on /boot/firmware type vfat (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)

Francois117
Posts: 11
Joined: Thu Apr 07, 2016 11:26 pm

Re: filesystem write files - after reboot the old data is ba

Mon Apr 11, 2016 8:14 pm

Sooo... Three days later.
I managed to find an older version of my development SD card and cloned it onto the SD card of the system that was showing this weird non-write error. And guess what - after the dd, the SD card still had all the old data! Like the dd did not happen!

Somehow it fools the ubuntu 14 OS the think that the writes are succesful, and comitted to SD card disk. But after a reboot, the SD card is back to the state it was in before any writes!

BEWARE: SD card fail in weird ways!

Heater
Posts: 13924
Joined: Tue Jul 17, 2012 3:02 pm

Re: filesystem write files - after reboot the old data is ba

Mon Apr 11, 2016 8:20 pm

Francois117,
BEWARE: SD card fail in weird ways!
No.

Maybe your Ubuntu fails in weird ways, which it does but I don't think that is the problem here.

Can you try an experiment for us:

1) Write some stuff to some file.

2) Issue a synch command

Code: Select all

$ synch
3) Restart the the thing in whatever way you normally do.

4) Report the content of "some file". Is it the "some stuff" you wrote to it in 1) above?
Memory in C++ is a leaky abstraction .

Conjur
Posts: 17
Joined: Wed Apr 06, 2016 8:55 pm

Re: filesystem write files - after reboot the old data is ba

Mon Apr 11, 2016 8:32 pm

Another possibility is a fake sd card. Chinese 8gb sd cards only hold about 3g before start ignoring writes.

tpylkko
Posts: 383
Joined: Tue Oct 14, 2014 5:21 pm

Re: filesystem write files - after reboot the old data is ba

Mon Apr 11, 2016 8:44 pm

+1 fake card. The hacked firmware in the fake cards is lying to the OS (Ubuntu) that they are taking in the data, when they in fact are not.

ejolson
Posts: 3830
Joined: Tue Mar 18, 2014 11:47 am

Re: filesystem write files - after reboot the old data is ba

Tue Apr 12, 2016 2:04 am

tpylkko wrote:+1 fake card. The hacked firmware in the fake cards is lying to the OS (Ubuntu) that they are taking in the data, when they in fact are not.
I heard that repeated power failures can cause the sdcard firmware to become confused what parts of the flash memory are available for use. A fake sdcard is also possible and perhaps more likely depending on where you purchased the card. Is it possible the write protect switch on the card got flipped? If you are wanting to create a system that is able to withstand power failures, then something other than the standard Raspbian configuration is needed. You may consider battery backed power such as used in notebook computers, cell phones and cameras to avoid a sudden power loss.

Francois117
Posts: 11
Joined: Thu Apr 07, 2016 11:26 pm

more tests...

Tue Apr 12, 2016 7:06 am

This is the card:
Image
...
test 1:

Code: Select all

vim 1.test
and I entered many lines of text in it. Save.

Code: Select all

cat 1.test
shows the contents of the file.
reboot. file gone. no file, no contents.

...
test 2:

Code: Select all

vim 2.test
and I entered many lines of text in it. Save.

Code: Select all

cat 2.test
shows the contents of the file. I can't find the command synch - I assume you meant sync

Code: Select all

sudo sync
reboot. file gone. no file, no contents.

---
So now we are down to 1) fake card or 2) card firmware damaged or 3) write protect...
The fact that the OS shows the contents of all newly generated files...
...
test 3
-create 8kb text file. cp 10x. mv into dir. cp dir 10x. mv indo dir. cp 10x. etc etc. I end up with 800MB of recursive directories containing only 8kb text files. I can step into any one and cat it to see the contents.
- When I ask the OS to copy the files again, I get the following errors (I think is occurs when the ubuntu ram cache is full):

Code: Select all

cp: cannot stat ‘large/E/m7/l9/l6/format-text-underline.png’: Input/output error
cp: cannot stat ‘large/E/m7/l9/l6/format-direction-left-to-right.png’: Input/output error
cp: cannot stat ‘large/E/m7/l9/l6/format-text-bold.png’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l7/opt_allow_mail_to_commands.es.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l7/opt_swap_bangpath.sv.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l7/opt_best_mx_transport.es.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l7/opt_smtpd_recipient_restrictions.nl.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l7/opt_swap_bangpath.es.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l4/opt_smtp_helo_timeout.pl.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l4/opt_luser_relay.nl.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l4/opt_smtp_connect_timeout.sv.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l4/opt_smtp_connect_timeout.es.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l4/opt_smtp_skip_quit_response.es.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l4/opt_smtp_rcpt_timeout.es.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l1/alias_cmt.nl.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l1/opt_disable_vrfy_command.pl.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l9/opt_inet_interfaces.pl.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l9/opt_smtpd_error_sleep_time.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l9/transport.pl.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l9/transport.sv.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l9/opt_debug_peer_level.es.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l9/opt_smtpd_helo_required.sv.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l9/opt_virtual_maps.sv.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l9/opt_maps_rbl_reject_code.pl.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l9/opt_error_notice_recipient.pl.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l9/opt_smtpd_hard_error_limit.es.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l2/opt_local_transport.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l2/opt_alias_maps.es.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l2/opt_smtpd_client_restrictions.es.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l2/opt_always_bcc.es.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l2/master.nl.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l2/opt_disable_vrfy_command.sv.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l2/opt_maximal_queue_lifetime.ca.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l3/opt_sample.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l3/opt_program_directory.nl.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l3/alias_name.nl.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l3/bcc.ca.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l10/opt_swap_bangpath.ca.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l10/opt_qmgr_message_active_limit.pl.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l10/opt_smtp_skip_4xx_greeting.ca.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l10/alias_to.pl.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l10/opt_minimal_backoff_time.ca.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l6/opt_smtp_quit_timeout.nl.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l6/opt_virtual_alias_maps.ca.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l6/general_opts.es.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l6/opt_error_notice_recipient.pl.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l6/opt_queue_directory.sv.UTF-8.html’: Input/output error
cp: cannot stat ‘large/E/m1/l6/l6/opt_swap_bangpath.es.html’: Input/output error
...and these errors have nothing to do with the files I am copying. I assume they are hidden writes that Ubuntu tries to write in the background that fails once I fill the ram cache. But file these strange file names are added to my test directory???

After reboot, my whole recursive directory structure is gone.

The most likely cause of the problem is the card firmware damaged. Which card brands would you suggest ?

User avatar
procount
Posts: 1854
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: filesystem write files - after reboot the old data is ba

Tue Apr 12, 2016 7:30 am

(Deleted -I missed the fact you had done sync test)
Last edited by procount on Tue Apr 12, 2016 7:43 am, edited 1 time in total.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

fruit-uk
Posts: 609
Joined: Wed Aug 06, 2014 4:19 pm
Location: Suffolk, UK

Re: filesystem write files - after reboot the old data is ba

Tue Apr 12, 2016 7:34 am

Your photo doesn't really say much. It is very easy for a manufacturer of fakes to copy and print someone else's style and logo

I use the cheapest cards I can find - but I will usually buy them from High Street stores I happen to pass through as I believe there is less chance of buying a fake - and I can take it back if defective.

User avatar
RaTTuS
Posts: 10506
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
Contact: Twitter YouTube

Re: filesystem write files - after reboot the old data is ba

Tue Apr 12, 2016 7:43 am

How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

ghans
Posts: 7878
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany

Re: filesystem write files - after reboot the old data is ba

Tue Apr 12, 2016 7:46 am

I've heard that SD cards can permanently switch into
read-only mode if they detect massive internal damage.

Or course every info about SD cards has to be top secret in the
eyes of the manufacturers i've never been able to confirm it.


ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org

fruit-uk
Posts: 609
Joined: Wed Aug 06, 2014 4:19 pm
Location: Suffolk, UK

Re: filesystem write files - after reboot the old data is ba

Tue Apr 12, 2016 7:51 am

ghans wrote:I've heard that SD cards can permanently switch into
read-only mode if they detect massive internal damage.
I have had that happen with USB sticks. It is said that some manufacturers do this to protect your data.:)
A search for sandisk readonly may show some hits

Francois117
Posts: 11
Joined: Thu Apr 07, 2016 11:26 pm

next card worked fine - much slower.

Tue Apr 12, 2016 8:09 am

So I booted another pi with a similar version of ubuntu 14.
- also created a recursive directory structure but it took much longer.
- copying recursive directories is very slow.
- the disk access LED stayed on long after the writes "finish" and control comes back to the command line.
- sync took 1 min after writing 512MB data - on the damaged card it was very fast.
- after reboot the recursive directory structure and all files were there.
speed tests:
Write speed: 524288000 bytes (524 MB) copied, 56,6973 s, 9,2 MB/s
Read speed: 524288000 bytes (524 MB) copied, 29,5167 s, 17,8 MB/s

Francois117
Posts: 11
Joined: Thu Apr 07, 2016 11:26 pm

need tool for detect read-only SD card

Tue Apr 12, 2016 8:18 am

My huge issue with this is that I can't easily detect when the card goes faulty! The operating system continues normally and shows all the new disk contents as if nothing is wrong and everything has been written.

As fas as I can see there are only two ways of detecting this:
1) write more incompressible data than the RAM to the disk and detect io errors - this is not practical in a deployed environment
2) write contents to a file, reboot and test that the content is there. I could possibly do this during off-times (3AM...) but it will take some thinking... I need to test for a new random string after a reboot, but I can't trust the file system... How do I know what to look for? maybe use the date... mmm

Any bright ideas to test this in order to report back that the SD disk is damaged?

edo1
Posts: 136
Joined: Sun Jun 15, 2014 3:33 pm
Location: Russia

Re: filesystem write files - after reboot the old data is ba

Tue Apr 12, 2016 8:26 am

fruit-uk wrote:I have had that happen with USB sticks.
same here

fruit-uk
Posts: 609
Joined: Wed Aug 06, 2014 4:19 pm
Location: Suffolk, UK

Re: need tool for detect read-only SD card

Tue Apr 12, 2016 8:28 am

Francois117 wrote:Any bright ideas to test this in order to report back that the SD disk is damaged?
Add a USB stick, copy writes to that and compare with SD

Francois117
Posts: 11
Joined: Thu Apr 07, 2016 11:26 pm

Re: need tool for detect read-only SD card

Tue Apr 12, 2016 8:39 am

Add a USB stick, copy writes to that and compare with SD
... add more hardware, that can fail too? ;)

I get the realtime clock initialised about two minutes after boot - maybe I can read a file that should have yesterday's date... if it has yesterday's date, then write today's date to it, and then reboot tomorrow morning randomly between 1am and 3am.
If it doesn't contain yesterday's date, report faulty disk to main server...

The sad thing is that I have to reboot and it means about two minutes where the 3G is offline and the device date is 1 Jan 1970.
Last edited by Francois117 on Tue Apr 12, 2016 8:42 am, edited 1 time in total.

Heater
Posts: 13924
Joined: Tue Jul 17, 2012 3:02 pm

Re: filesystem write files - after reboot the old data is ba

Tue Apr 12, 2016 8:40 am

ghans,
I've heard that SD cards can permanently switch into read-only mode if they detect massive internal damage.
I have had this happen to me with a three or four SD cards back in early days of the Pi.

In some cases the entire SD was unwritable.

In some cases some blocks of the card could be written and others not.

Normal formatting under Windows would report "Write Protected"

I wasted a few hours dd'ing stuff on and off those cards and checking what happened with md5sum. I could see that some areas got written and others did not.

It was driving me nuts at the time, different makes of card, different Pi, failures all the time.

Oddly I have not seen any such problems in the last three years.
Memory in C++ is a leaky abstraction .

tpylkko
Posts: 383
Joined: Tue Oct 14, 2014 5:21 pm

Re: filesystem write files - after reboot the old data is ba

Tue Apr 12, 2016 9:38 am

I read somewhere that something in the order of 80% of all sd cards sold on the net are fake. It is a criminal scam and it works like this: Factories make flash memory, but not all the made chips pass the quality tests and are then classified as "rejected" and destroyed. However, since these factories are in places like China, organized crime has a good chance of getting their hand on these "rejects" instead. So they doctor the firmware on the chip to lie to the OS that it is okay and has a lot of memory. The rejected chip might be a 4 G chip, but they sell it as a 16 GB one. The scam works because most normal users never fill up their stick, and if the stick becomes full the doctored firmware on the device starts to dump data while appearing as if a normal copying is still occurring. The doctored firmware will keep data in the OS's disk cache, so it will appear that the data is there when it is not. There are two ways to know it is a fake: 1) open the chip and get a serial number that you can trace or 2) take one large file the nearly fills up the device and copy it to the device. Then unmount it and take it to another computer. Then try to recover the entire file without any errors.

They, of course, gain a lot of money doing this since most people never notice or when they do, it is at such a later time that they think they just wore out the card/stick.

So, the rational strategy is to not purchase these things of the net, especially ebay. You can buy other things that don't matter if they are fake or not (cheap plastic cases for the pi or whatever) from the Chinese off of ebay, but don't buy flash. Buy USB sticks and sd cards from a local vendor of reputation.

See:

http://www.ebay.com/gds/All-About-Fake- ... 258/g.html

http://www.ebay.com/gds/BEWARE-of-FAKE- ... 438/g.html

http://www.instructables.com/id/Dont-fa ... Drive-Scam!/

https://fightflashfraud.wordpress.com/page/2/

http://www.myce.com/news/fake-and-count ... zon-72165/

Conjur
Posts: 17
Joined: Wed Apr 06, 2016 8:55 pm

Re: filesystem write files - after reboot the old data is ba

Tue Apr 12, 2016 9:46 pm

Simple Solution:

create a small partition (like 1mb) on the sd card (say... /dev/sda4), and mkfs.ext4 /dev/sda4
I have not confirmed this script, so it may have stupid errors, but in theory; if the SD card is not retaining data, it will NOT retain data through umounting and mounting. If the data is successfully written to the disk, this should yield the same number. if not, it will error out about reading /tmp/foo.$WINNER/poo; saying that the file does not exist.

Keep in mind, that running this too frequently will fudge the sectors of the SD Card that the test partition is on; so stick to a maximum of hourly or so. (assuming that the SD card does not have proper wear-leveling firmware, which most do not)

Test this on your "known-bad" system

#!/bin/sh
WINNER=$RANDOM

mkdir /tmp/foo.$WINNER
mount /dev/sda4 /tmp/foo.$WINNER
echo -n $WINNER >/tmp/foo.$WINNER/poo
umount /tmp/foo.$WINNER
sync
mount /dev/sda4 /tmp/foo.$WINNER
READWINNER=$(cat /tmp/foo.$WINNER/poo)
umount /tmp/foo.$WINNER
rm -rf /tmp/foo.$WINNER

echo "Wrote $WINNER to file"
echo "Read $READWINNER back, after re-mounting"

User avatar
jojopi
Posts: 3088
Joined: Tue Oct 11, 2011 8:38 pm

Re: filesystem write files - after reboot the old data is ba

Tue Apr 12, 2016 10:32 pm

Conjur wrote:in theory; if the SD card is not retaining data, it will NOT retain data through umounting and mounting.
If the data are only being retained in the kernel's buffer cache and not on the card, just dropping the caches should be sufficient to make recent changes disappear.

Code: Select all

touch TESTFILE
stat TESTFILE
sync
echo 3 |sudo tee /proc/sys/vm/drop_caches
stat TESTFILE

Return to “General discussion”