I am wondering if it is possible to have a usb key in a raw format and still read/write files on it.
It should be cross-platform and understood by a dedicated software we ship.
I am kind of creating a non-bootable file system in a hurry, and I just need to read/write some values at some offsets on this raw storage space.
People who will use it will be shipped the software able to read those values (not the operating system who will surely see raw/free space, but we don't care about that).
Will I run into troubles with the mounting, or whatever?
Or is it green light?
Thanks
Yes, absolutely, you can read and write the "unformatted" SD card or USB memory. You can also format it to whatever filesystem you need by writing to pages of that memory. The only possible difficulty is that the OS (at least later Windows versions) might not allow writing to the disk if the user account doesn't have admin rights.
Related
Today I just realized in my Ubuntu Linux, I can mount and store files on my newly purchased hard drive as a raw device without a file system. (as long as I partitioned the disk correctly)
So, I am not sure if my below statement is correct, looking for expert to answer:
Looks like it's not required to create a file system on a disk in order to use it in Linux? Is it correct?
I have some very basic understanding of how a file system works. In Linux, is the concept of "inode" a file system feature or a Linux feature?
I understand that the "inode" file system works unlike NTFS or FAT32 that it tries to spread out the data across the disk so that Linux/Unix doesn't need as Windows like "defgramentation" program to keep data in consecutive chunks. My question is, if I am storing my data on a raw device without a file system, and if "inode" is a file system feature not a Linux feature, what will the actual data layout look like on the raw device then?
Thanks in advance
I have hard time to decide that which filesystem is the best and Raid or not Raid selection. I have 4 different hard disk.
1. 120GB SSD
2. 160GB
3. 500GB
4. 1TB
And I have noticed that zfs on linux does not support trim officially but third party patch, therefore, it is not fully tested....
As a result, I don't intend to let my ssd use zfs, I will use ext4 instead...
So, Is zfs on linux reliable enough to be installed with gentoo on a network attached storage?
Or you guys have another good solution for me?
P.S. if zfs is reliable enough, RAIDZ is a good choice?
Define "reliable enough". If you're expecting bug-free operation, then no, it simply is not there yet. If you're happy to potentially pick up the pieces from a total failure of the file system, then it's good enough.
If your data has any value and you're talking about a production machine, do not touch unproven file system drivers with a barge pole unless you know exactly what you're getting into. A third-party patch for TRIM is definitely living on the edge.
If you desperately want to use ZFS, use FreeBSD where it is more mature. If you're sticking with Linux, I would personally keep to ext4. It's a solid system, and the drives you're talking about don't really demand the benefits of ZFS, in my opinion.
In your description you mention a set of disks you want to use. If you would use this set in e.g. RAIDZ and one disk crashes, your disk-array would lose all its data.
Reliability is a very broad expression;
If you want to protect your data agains bit-rot, then ZFS is an excellent choice.
If you would use it with your available disks and you would like to protect your data against hardware failures, consider using a more homogene set of disk.
Regarding your selection of OS, try OpenIndiana http://openindiana.org/ or some turn-key OS like http://www.freenas.org/ for relatively simple (but effective) configurations.
Open Indiana is very reliable but a huge pain to run. FreeBSD has ZFS support built in. however (depending on what you are doing and how reliable you need) I would install it on Ubuntu if there is any margin for error.... if not.. then use Open Indiana or FreeBSD
Using linux, I can use raw access to NAND or access to files through filesystem. So, when I need to know, where my file is really located in NAND, what should I do? I cannot found any utilities providing this feature. Moreover, I cannot detect any possibility of this, besides hacking kernel with tons of "printk" (it's not nice way, I guess).
Can anybody enlighten me on this? (I'm using YAFFS2 and JFFS2 filesystems)
You can make a copy of any partition with nanddump. Transfer that partition dump to a PC. The nandsim utility can be used to mount the partitions on a PC.
modprobe nandsim first_id_byte=0x2c second_id_byte=0xda \
third_id_byte=0x90 fourth_id_byte=0x95 parts=2,64,64
flash_erase /dev/mtd3 0 0
ubiformat /dev/mtd3 -f rootfs.ubi
This command emulates a Micron 256MB NAND flash with four partitions. If you just capture the single partition and not the whole device, don't set parts. You can also do nanddump on each partition and then concatenate them all. This code targeted mtd3 with a UbiFs partition. For JFFS2 or YAFFS2, you can try nandwrite or some other appropriate flashing utility on the PC.
How to get real file offset in NAND by file name?
The files may span several NAND sectors and they are almost never contiguous. There is not much of an advantage to keep file data together as there is no disk head that takes physical time to seek. Some flash has marginally better efficiency for sequential reads; yet other flash will give better performance for reads from another erase block.
I would turn on debug at either the MTD layer or in the filesystem. In a live system, the position of the file may migrate over time on the flash even if it is not written. This is active wear leveling.
Is there a way to purposefully corrupt a FAT file system using only Win32 calls or must you do it at lower level? We're encountering FAT corruption on a WinCE 5.0 device and have written a utility to detect and attempt to correct it, but don't have a means to create FAT corruption on demand. Thanks.
The media is a CF card, but it's not removable as a normal course as it's mounted internal to the device.
What's the FAT on (e.g. inserted USB, on-board flash, etc)? That's going to make a large difference.
If it's the on-board flash, you need to get underneath the file system driver (FSD), which is typically going to be the flash driver itself. It's going to have access to the raw flash sectors (it's what the FSD uses for its reads and writes) either through Xxx_Write or Xxx_Ioctl. Exactly how it works is going to depend on the flash driver in use, so looking at the driver source is your best path.
You can access device data as a raw file and write random data in that file to corrupt FAT. E.g. if you write random data on:
\?\Device\HarddiskVolume1
This would corrupt first partition.
This page has some hints on how to figure out paths for HDD/USB drive etc.
http://www.chrysocome.net/dd
i want to copy nk.bin to partition on wince 6.0.
i want that when i restart device then using redboot cammand it should be able to load nk.bin from partion. how to do this?
This is a broad and pretty platform-specific question. Forst, you've not told us much about your platform, so we have to make assumptions. I'll assume, based on you using redboot and talking about "partitions" that you'r running on ARM and that your OS image is stored in persistent storage (i.e. Flash).
The next question is "How and where is the OS stored?" This is platform specific, so only you (or your OEM) can say. It might be inside a FAT 32 volume or it might be written raw to a specific location in flash outside of any file system. If it's the former (it's probably not, or you likely wouldn't be asking the question), you could copy it. If it's just at some location raw, you're going to need APIs to directly access the flash. See if the OEM provided them (apps can't map direct to hardware in 6.0, so if there's no OEM-provided API, you'll have to write a driver).
You also need to know if you're XIP. If so, I don't think you're going to be able to copy the OS while it's running - at least I'd consider it a high-risk operation. In that case you likely need to set some sort of bit somewhere outside the existing file system (an EEPROM, scratch-pad regiter, raw flash, etc) and reboot, then modify the bootloader to make the copy.
THis all assumes you mean you want to copy it from on the device itself. You could mean you want to copy it using a JTAG tool as well, in which case everything I've said is irrelevant (except the location of the OS - and even that's not relevant if you're thinking you want to copy it from an outside source).