Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
Last night I have done quite an idiotic thing. In an attempt to delete USB from my friend i have accidentally started
dd if=/dev/zero of=/dev/MyBootDrive
and killed first couple of gigabytes of data from my disk. That data is absolutely not important, i have killed system that needed to be replaced in the first place but. On that partition there is a significant amount of data that should be saved if anyhow possible.
So is there any tool that could make me feel less idiot I obviously am, and save my data from filesystem corrupted like that. I'm aware of some tools but they usually save deleted data, or when partition is changed.
Thanks
Well ext4 replicates the superblock so you can use tools like gpart to find the partition again.
Then also, ext4 stores all the necessary information to read a block group at the beginning of such group. So theoretically it should be possible to restore all the preserved block groups.
It might work to run fsck and point it to a superblock that you might have found (or calculated where it might be).
However, when we lastly tried this, it didn't work for us (but we wrote a new file system over the old one, /dev/zero might be better). We then tried to find files in the raw data, igoring the file system. We could not recover much meaningful data. It is easier for multimedia files than text files though.
Ok I have managed to rescue everything.
It was not magic, I was just plain lucky. I have realized what I'm doing and stopped command after a bit more than 1 sec. So I have nulled just first 1.4GB of data. That was my boot disk, and naturally my / partition was the only one damaged. So obviously every other partition is left intact. But since my partition table is destroyed everything I was able to see is empty hdd. First thing I tried was to recover partitions with gpart but to no avail.
After that I have found this article. Using test disk i have managed to save my /home partition and all data from it.
Now everything is finished I have to agree with the end of this artice:
Well, that would be all. Forget recovery. It's so 70s. Go for backups!
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
By default, the ext2/3/4 fs reserves 5% of its capacity to be able to keep running when diskspace is getting low.
I also believe it has something to do with allowing "fragmentation between files" or something like this (I haven't been able to find concrete information about this, and I'm kinda newbie in this domain).
My question is: when do we need to keep these 5%, when can we reduce it to something like 1-2%, or when can we remove it totally ?
The elements that I'm considering atm are the following:
The 5% rule was decided something like 20 years ago when the reserved size wasn't way more than ~100Mbs, which is totally different now; if we're only talking about space needed to execute commands and such, do we really need 20Gbs ?
Could it ever be a good idea to remove this allowed space ? If some of it is needed for "fragmentation" somehow, I believe we should at least keep 1-2% available
Is this space really only useful for partitions that are related in any way to root ? I mean, if we have a partition for some folder in /home (something personal, or data from a database, something else that is not related in any way to the OS), this space may not be needed
I've only seen more and more articles on the web telling about how to reduce the reserved blocks so I believe that it may not be a bad idea 100% of the time, but I've not really been able to have articles explaining deeply the concrete application of "when it can / cannot be used", and "what it exactly does and implies".
So if some of you could provide comprehensive information (as well as a simple answer to the question I exposed above) I would be very thankful.
Those 5% are really kept for root user to be able to login and do some operations in case of full filesystem. And yes, you can decrease the amount (I did this in the past) to 1-2% (depend of the disk size). But be aware for most filesystems this should be defined when you create it and its hard (if possible at all) to change it after.
About zero it - yes, that's also possible. But will be wise to keep some space for root in the /, /root (or whatever is the home of root user), /tmp and eventually /var/tmp
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
According to kernel.org there is the possibility to store dentries in trees instead of lists but you need to enable this flag (EXT4_INDEX_FL) in the inode structure. I this enabled by default or I have to format my partition with some flags?
I need to store lots of small files (same old problem) of about 130k each and I understood that this will help to speed up lookup and also that it is recommended to store those files in a 2 level directories hierarchy. Is there something else I need to consider so that this doesn't blow up if want to store something close to 60.000.000 of this kind of files ? (maybe some other values for block size, number of blocks in a group)
This option is referred to by the e2fsprogs suite as dir_index. It's enabled by default, and you can verify that it's enabled on a file system by running tune2fs -l DEVICE as root.
It is indeed recommended that you shard your files manually so that you don't have a huge number of files in the same directory. While using B-trees makes the operation O(log n) instead of O(n), for large numbers of files, the operation can still be expensive.
If you know you're going to be creating a large number of files, you can set the inode ratio to 4096 with the -i option; this will create a larger number of inodes so that you can hold more files. You can also see common settings for a large number of situations in /etc/mke2fs.conf.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I'm running shred against blockdevice with couple of etx4 filesystems on it.
The blockdevices are virtual drives - RAID-1 and RAID-5. Controller is PERC H710P.
command
shred -v /dev/sda; shred -v /dev/sdc ...
I can understand from shred man(info) page that shred might be no effective on journal filesystems but only when shredding files.
Anyone can please explain whether is shredding against blockdevice safe way to destruct all data on it?
This is a complex issue.
The only way that is 100% effective is physical destruction. The problem is that the drive firmware can mark sectors as bad and remap them to a pool of spares. These sectors are effectively no longer accessible to you but the old data may be recoverable from those sectors by other means (such as an alternate firmware or physically removing the platters).
That being said, running shred on the block device does not have the issues due to journaling.
The problem with journaling is that for partial overwrites to be recoverable you cannot actually overwrite the original data, so the overwrite of the file takes place in a second physical location, leaving the first in tact. Writing directly to the block device is not subject to journaling.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
What would happen if the Linux kernel deleted itself? Will there be a moment when it could no longer delete files because rm or the program used for deletion has been deleted too?
Regards.
The question is (apart from being off-topic) somewhat wrong in itself, as rm is not part of the kernel, but either a shell built-in or a separate user-level program. Admittedly, rm uses a syscall provided by the kernel, but that is irrelevant.
The kernel itself is loaded from a compressed image and locked in RAM. It does not matter whether you delete the compressed image until you reboot (which will fail with the boot loader giving you a message like "vmlinuz not found"). You have no way of removing the kernel from RAM (well, other than rebooting...).
Also, for the most part, it does not even matter whether you delete a file, including a running program's executable anyway (if we may be so daunting as to call the kernel a "program" for a moment) under Linux, because deleting a file merely removes the link, not the file. It is a Windows-typical assumption that deleting a file does evil, destructive things.
Under Unix-like systems, it is perfectly possible to delete (or replace) a program while it is running, and it will not cause any problems at all. You will remove the name in the filesystem, that's all. Any open descriptors will remain valid until the last one is closed, the original file will stay intact as-is for any observer who obtained a handle earlier, and it will be "gone" for everyone trying to get at it later.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I've read that turning off atime and diratime can be beneficial to I/O performance, but I've never seen a good example of what would and would not benefit. When should I do this?
If you want a solid example of when you would specify noatime in the options for a partition, imagine a data partition containing the files for a database. This database is mainly read from (not written to) and the queries are frequent and small in size. If you have atime enabled, every read operation (fast) that hit the disk would actually turn into a write operation (slow) because atime would have to be updated every time something is accessed.
This is particularly noticeable when you are using a potentially slow disk (think EBS on Amazon with some performance issues).
So, in any case where you expect to be doing a lot of reading from a filesystem and you wan to prevent latency due to disk IO, turn off atime :)
atime is the time of last access. That means that it has to be updated on disk each time a file is read, even if there is no other modification in the data/metadata of the file.
And since most programs read files, even whether they do not write at them, it is always beneficial for the performance to turn off this options.
Unless, of course, you need it. Because, as you probably know, atime is mandated by Posix, and there are some old software out there that relies on it.