Search Results

Search found 186 results on 8 pages for 'inode'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 1/8 | 1 2 3 4 5 6 7 8  | Next Page >

  • Adding files and folders to a Root Folder (inode/directory)

    - by xBaldwin
    Ok so I'm fairly new to Ubuntu and wasn't even the one who put it one this computer(my friend did while I was storing it at his house because I was in the middle of transitioning between houses), but It's on here so I need to learn what I can so I can use it more effectively. My question at the moment is "Would it be safe to add files/folders to a folder (inode/directory) that requires Root access?" I continue to be informed by the system that the directory I am using is running low on space which I found odd seeing how I should have a lot more room on this computer. That's when I started looking at the directories and found that there are two with a bunch of un-used space on them. One says it has 46.9 GB of free space and the other has 24.9 GB of free space. Seems like a complete waste to not use that space and yet they both say they require Root access to add to them. I know that Root folders and files are normally all system folders and files. I also know that changing or deleting them can mess up the computer which right now I cant afford to do. I just don't know if it would mess anything up to add something to those folders. Thank you in advance to anyone who takes the time to reply and try to teach me about how all that works. I really do appreciate it and will do the same if by some crazy (completely unlikely) reason I have an answer to your question. :-)`

    Read the article

  • Linux: Why to change inode size?

    - by FractalizeR
    Hello. Tune2fs allows to change inode size from default 128 bytes to almost anything (but it should be power of two). What can the the reasons of changing default inode size? Here http://kbase.redhat.com/faq/docs/DOC-7433 is written, that this can be done to be able to store ACL attributes inside inodes. What else can be stored inside inode? May be some other attributes? Or anything else? Is there any reason to increase inode size on modern high-capacity drives (2TB and more)?

    Read the article

  • Strange Inode/Ram cache drops happening in CentOS

    - by FunkyChicken
    I run a CentOS 5.7 machine (64bit) with 24GB ram and 4x SAS drives in RAID10 setup. This machine runs nginx/1.0.10, php-fpm & xcache. About a month back the RAM usage of this machine has changed. About every few hours the 'CACHE' is flushed from the RAM, this happens exactly when the 'Inode table usage' drops. I'm pretty sure these drops are related. (see the 2 attached images). This server hosts quite a lot of small files (20M all a few KB big). Not many files are deleted (maybe 100 per hour (total size a few MB max)), not enough to account for the huge Inode table drops. I also have no crons running which could cause these drops. Sar -r output: http://pastebin.com/C4D0B79i My question: Why are these huge RAM/Inode usage drops happening? How can I get Nginx/PHP to use all of my servers RAM?

    Read the article

  • Determine Location of Inode Usage

    - by Dave Forgac
    I recently installed Munin on a development web server to keep track of system usage. I've noticted that the system's inode usage is climbing by about 7-8% per day even though the disk usage has barely increased at all. I'm guessing something is writing a ton of tiny files but I can't find what / where. I know how to find disk space usage but I can't seem to find a way to summarize inode usage. Is there a good way to determine inode usage by directory so I can locate the source of the usage?

    Read the article

  • Remove a file on linux using the inode number

    - by WebDevHobo
    If you create a file on UNIX/linux with special chars, like touch \"la*, you can't remove it with rm "la*. You have to use the inode number(you can if you add the \ before the name, I know, but you'd have to guess as a user that it was used in the file creation). I checked the manpage for rm, but there's no metion of the inode number. Doing rm inodenumber doesn't work either. What is the command for this?

    Read the article

  • Abnormal hangs and restarts Ubuntu 8.04

    - by jai-ho
    Hi, I am using Ubuntu 8.04 LTS and seeing the following behaviors: The system hangs after a while and becomes completely unresponsive. The system sometimes restarts itself ! Can you please help me identify what is the problem? Also please mention where should I look for the possible cause of this error. Thanks. EDIT: Got the following from the dmesg output (the system got hung and had to restart) [ 15.452015] Driver 'sr' needs updating - please use bus_type methods [ 15.456882] Driver 'sd' needs updating - please use bus_type methods [ 15.457987] sr0: scsi3-mmc drive: 52x/52x writer cd/rw xa/form2 cdda tray [ 15.457993] Uniform CD-ROM driver Revision: 3.20 [ 15.458058] sr 0:0:1:0: Attached scsi CD-ROM sr0 [ 15.463028] sd 1:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB) [ 15.463051] sd 1:0:0:0: [sda] Write Protect is off [ 15.463055] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 15.463083] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 15.463151] sd 1:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB) [ 15.463167] sd 1:0:0:0: [sda] Write Protect is off [ 15.463171] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 15.463197] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 15.463202] sda:<5sr 0:0:1:0: Attached scsi generic sg0 type 5 [ 15.464634] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 15.470120] sda1 sda2 < sda5 [ 15.495536] sd 1:0:0:0: [sda] Attached SCSI disk [ 15.759549] Attempting manual resume [ 15.759554] swsusp: Resume From Partition 8:5 [ 15.759556] PM: Checking swsusp image. [ 15.759742] PM: Resume from disk failed. [ 15.779964] EXT3-fs: INFO: recovery required on readonly filesystem. [ 15.779970] EXT3-fs: write access will be enabled during recovery. [ 19.904204] kjournald starting. Commit interval 5 seconds [ 19.904235] EXT3-fs: sda1: orphan cleanup on readonly fs [ 19.904245] ext3_orphan_cleanup: deleting unreferenced inode 303260 [ 19.904304] ext3_orphan_cleanup: deleting unreferenced inode 303329 [ 19.932763] ext3_orphan_cleanup: deleting unreferenced inode 3801871 [ 19.932785] ext3_orphan_cleanup: deleting unreferenced inode 3801874 [ 19.932798] ext3_orphan_cleanup: deleting unreferenced inode 3801910 [ 19.951253] ext3_orphan_cleanup: deleting unreferenced inode 3801912 [ 19.951266] ext3_orphan_cleanup: deleting unreferenced inode 3801914 [ 19.951278] ext3_orphan_cleanup: deleting unreferenced inode 3959212 [ 19.951299] ext3_orphan_cleanup: deleting unreferenced inode 3959213 [ 19.960335] ext3_orphan_cleanup: deleting unreferenced inode 3959215 [ 19.963531] ext3_orphan_cleanup: deleting unreferenced inode 3801875 [ 19.963545] ext3_orphan_cleanup: deleting unreferenced inode 3663727 [ 19.963565] ext3_orphan_cleanup: deleting unreferenced inode 3663708 [ 19.963577] ext3_orphan_cleanup: deleting unreferenced inode 4072122 [ 19.963597] ext3_orphan_cleanup: deleting unreferenced inode 4072157 [ 19.968616] ext3_orphan_cleanup: deleting unreferenced inode 4072159 [ 19.970252] ext3_orphan_cleanup: deleting unreferenced inode 4072160 [ 19.970264] ext3_orphan_cleanup: deleting unreferenced inode 4072161 [ 19.992889] ext3_orphan_cleanup: deleting unreferenced inode 4072264 [ 19.992903] ext3_orphan_cleanup: deleting unreferenced inode 4072267 [ 19.999585] ext3_orphan_cleanup: deleting unreferenced inode 4072268 [ 20.008329] ext3_orphan_cleanup: deleting unreferenced inode 4072270 [ 20.008343] ext3_orphan_cleanup: deleting unreferenced inode 4072123 [ 20.008360] ext3_orphan_cleanup: deleting unreferenced inode 4072452 [ 20.008374] ext3_orphan_cleanup: deleting unreferenced inode 4072453 [ 20.008385] ext3_orphan_cleanup: deleting unreferenced inode 4072124 [ 20.008398] ext3_orphan_cleanup: deleting unreferenced inode 311574 [ 20.008413] ext3_orphan_cleanup: deleting unreferenced inode 967890 [ 20.008420] EXT3-fs: sda1: 28 orphan inodes deleted [ 20.008423] EXT3-fs: recovery complete. [ 20.082622] EXT3-fs: mounted filesystem with ordered data mode. [ 29.025379] input: PC Speaker as /devices/platform/pcspkr/input/input2 [ 29.187133] Linux agpgart interface v0.102 [ 29.225338] iTCO_vendor_support: vendor-support=0 [ 29.259662] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.02 (26-Jul-2007)

    Read the article

  • 'inode table usage' spiking every morning at 8am

    - by Harry Wood
    I installed munin on my ubuntu server. It's showing my 'inode table usage' spiking every morning at 8am. It then rapidly curves down and settles over the course of several hours. What might cause this? I thought it might be something running in /etc/cron.daily but this was set to run at 6a.m. and I've changed it to 4am. The spike remains at 8am. I also enabled cron logging, but can't see anything getting launched at 8a.m. It's a virtual server hosted by memset. Could it be caused by something happening on the virtual host?

    Read the article

  • rkhunter warns of inode change by no file modification date changes

    - by Nicholas Tolley Cottrell
    I have several systems running Centos 6 with rkhunter installed. I have a daily cron running rkhunter and reporting back via email. I very often get reports like: ---------------------- Start Rootkit Hunter Scan ---------------------- Warning: The file properties have changed: File: /sbin/fsck Current inode: 6029384 Stored inode: 6029326 Warning: The file properties have changed: File: /sbin/ip Current inode: 6029506 Stored inode: 6029343 Warning: The file properties have changed: File: /sbin/nologin Current inode: 6029443 Stored inode: 6029531 Warning: The file properties have changed: File: /bin/dmesg Current inode: 13369362 Stored inode: 13369366 From what I understand, rkhunter will usually report a changed hash and/or modification date on the scanned files to, so this leads me to think that there is no real change. My question: is there some other activity on the machine that could make the inode change (running ext4) or is this really yum making regular (~ once a week) changes to these files as part of normal security updates?

    Read the article

  • Reverse lookup of inode/file from offset in raw device on linux and ext3/4?

    - by lilinjn
    In linux, given an offset into a raw disk device, is it possible to map back to an partition + inode? For example, suppose I know that string "xyz" is contained at byte offset 1000000 on /dev/sda: (e.g. xxd -l 100 -s 1000000 /dev/sda shows a dump that begins with "xyz") 1) How do I figure out which partition (if any) offset 1000000 is located in?(I imagine this is easy, but am including it for completeness) 2) Assuming the offset is located in a partition, how do I go about finding which inode it belongs to (or determine that it is part of free space) ? Presumably this is filesystem specific, in which case does any one know how to do this for ext4 and ext3?

    Read the article

  • How to clean up an unprocessed orphan inode list?

    - by bmk
    I tried to mount a formerly readonly mounted filesystem read-writeable: mount -o remount,rw /mountpoint Unfortunately it did not work: mount: /mountpoint not mounted already, or bad option dmesg reports: [2570543.520449] EXT4-fs (dm-0): Couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead A umount does not work, too: umount /mountpoint umount: /mountpoint: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) Unfortunately neither lsof of fuser don't show any process accessing something located under the mount point. So - how can I clean up this unprocessed orphan list to be able to mount the filesystem again without rebooting the computer?

    Read the article

  • Unable to boot to Ubuntu. Inconsistency in disk, X server didn't start. Illegal blocks in Inode

    - by becomingGuru
    I am unable to boot into my Ubuntu system. First I get that fsck died with exit status 4 Then I try to do it manually as prompted and I get that an Inode has illegal blocks and asked to clear it. Upon googling, I found that is because my HD has some problems I booted via Live cd and took a dd of the entire Ubuntu on an external HDD just in case. Is it safe to clear all the illegal blocks. How do I safely restore my environment if I replace my HD. Is there any thing i can do in the meanwhile to continue to use my laptop without significant loss of data. Perhaps a related error, the x server fails to start

    Read the article

  • Causes of sudden massive filesystem damage? ("root inode is not a directory")

    - by poolie
    I have a laptop running Maverick (very happily until yesterday), with a Patriot Torx SSD; LUKS encryption of the whole partition; one lvm physical volume on top of that; then home and root in ext4 logical volumes on top of that. When I tried to boot it yesterday, it complained that it couldn't mount the root filesystem. Running fsck, basically every inode seems to be wrong. Both home and root filesystems show similar problems. Checking a backup superblock doesn't help. e2fsck 1.41.12 (17-May-2010) lithe_root was not cleanly unmounted, check forced. Resize inode not valid. Recreate? no Pass 1: Checking inodes, blocks, and sizes Root inode is not a directory. Clear? no Root inode has dtime set (probably due to old mke2fs). Fix? no Inode 2 is in use, but has dtime set. Fix? no Inode 2 has a extra size (4730) which is invalid Fix? no Inode 2 has compression flag set on filesystem without compression support. Clear? no Inode 2 has INDEX_FL flag set but is not a directory. Clear HTree index? no HTREE directory inode 2 has an invalid root node. Clear HTree index? no Inode 2, i_size is 9581392125871137995, should be 0. Fix? no Inode 2, i_blocks is 40456527802719, should be 0. Fix? no Reserved inode 3 (<The ACL index inode>) has invalid mode. Clear? no Inode 3 has compression flag set on filesystem without compression support. Clear? no Inode 3 has INDEX_FL flag set but is not a directory. Clear HTree index? no .... Running strings across the filesystems, I can see there are what look like filenames and user data there. I do have sufficiently good backups (touch wood) that it's not worth grovelling around to pull back individual files, though I might save an image of the unencrypted disk before I rebuild, just in case. smartctl doesn't show any errors, neither does the kernel log. Running a write-mode badblocks across the swap lv doesn't find problems either. So the disk may be failing, but not in an obvious way. At this point I'm basically, as they say, fscked? Back to reinstalling, perhaps running badblocks over the disk, then restoring from backup? There doesn't even seem to be enough data to file a meaningful bug... I don't recall that this machine crashed last time I used it. At this point I suspect a bug or memory corruption caused it to write garbage across the disks when it was last running, or some kind of subtle failure mode for the SSD. What do you think would have caused this? Is there anything else you'd try?

    Read the article

  • How file permissions are stored in inode?

    - by Debadyuti Maiti
    Suppose there's two pc - "A" and "B". Then if A downloads a files from B , then what would be the file permission of that downloaded file? Is it possible that the downloaded file in A will have an Inode entry with all it's permissions from B & store B's user account as the owner ? If that's the case then is it impossible to change that files permission on A if "others" [as in user-group-others] doesn't have the right to write on that file? e.g. if this is the case , __x __x __x file.txt [On B] then what would be the file permission on A of that same file downloaded from B [e.g. through vsftpd]? __x __x __x file.txt [On A] or rw_x rw_x rw_x file.txt [On A] [i.e. defined by A's default umask value]

    Read the article

  • Is post-sudden-power-loss filesystem corruption on an SSD drive's ext3 partition "expected behavior"?

    - by Jeremy Friesner
    My company makes an embedded Debian Linux device that boots from an ext3 partition on an internal SSD drive. Because the device is an embedded "black box", it is usually shut down the rude way, by simply cutting power to the device via an external switch. This is normally okay, as ext3's journalling keeps things in order, so other than the occasional loss of part of a log file, things keep chugging along fine. However, we've recently seen a number of units where after a number of hard-power-cycles the ext3 partition starts to develop structural issues -- in particular, we run e2fsck on the ext3 partition and it finds a number of issues like those shown in the output listing at the bottom of this Question. Running e2fsck until it stops reporting errors (or reformatting the partition) clears the issues. My question is... what are the implications of seeing problems like this on an ext3/SSD system that has been subjected to lots of sudden/unexpected shutdowns? My feeling is that this might be a sign of a software or hardware problem in our system, since my understanding is that (barring a bug or hardware problem) ext3's journalling feature is supposed to prevent these sorts of filesystem-integrity errors. (Note: I understand that user-data is not journalled and so munged/missing/truncated user-files can happen; I'm specifically talking here about filesystem-metadata errors like those shown below) My co-worker, on the other hand, says that this is known/expected behavior because SSD controllers sometimes re-order write commands and that can cause the ext3 journal to get confused. In particular, he believes that even given normally functioning hardware and bug-free software, the ext3 journal only makes filesystem corruption less likely, not impossible, so we should not be surprised to see problems like this from time to time. Which of us is right? Embedded-PC-failsafe:~# ls Embedded-PC-failsafe:~# umount /mnt/unionfs Embedded-PC-failsafe:~# e2fsck /dev/sda3 e2fsck 1.41.3 (12-Oct-2008) embeddedrootwrite contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Invalid inode number for '.' in directory inode 46948. Fix<y>? yes Directory inode 46948, block 0, offset 12: directory corrupted Salvage<y>? yes Entry 'status_2012-11-26_14h13m41.csv' in /var/log/status_logs (46956) has deleted/unused inode 47075. Clear<y>? yes Entry 'status_2012-11-26_10h42m58.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47076. Clear<y>? yes Entry 'status_2012-11-26_11h29m41.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47080. Clear<y>? yes Entry 'status_2012-11-26_11h42m13.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47081. Clear<y>? yes Entry 'status_2012-11-26_12h07m17.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47083. Clear<y>? yes Entry 'status_2012-11-26_12h14m53.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47085. Clear<y>? yes Entry 'status_2012-11-26_15h06m49.csv' in /var/log/status_logs (46956) has deleted/unused inode 47088. Clear<y>? yes Entry 'status_2012-11-20_14h50m09.csv' in /var/log/status_logs (46956) has deleted/unused inode 47073. Clear<y>? yes Entry 'status_2012-11-20_14h55m32.csv' in /var/log/status_logs (46956) has deleted/unused inode 47074. Clear<y>? yes Entry 'status_2012-11-26_11h04m36.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47078. Clear<y>? yes Entry 'status_2012-11-26_11h54m45.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47082. Clear<y>? yes Entry 'status_2012-11-26_12h12m20.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47084. Clear<y>? yes Entry 'status_2012-11-26_12h33m52.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47086. Clear<y>? yes Entry 'status_2012-11-26_10h51m59.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47077. Clear<y>? yes Entry 'status_2012-11-26_11h17m09.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47079. Clear<y>? yes Entry 'status_2012-11-26_12h54m11.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47087. Clear<y>? yes Pass 3: Checking directory connectivity '..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953). Fix<y>? yes Couldn't fix parent of inode 46948: Couldn't find parent directory entry Pass 4: Checking reference counts Unattached inode 46945 Connect to /lost+found<y>? yes Inode 46945 ref count is 2, should be 1. Fix<y>? yes Inode 46953 ref count is 5, should be 4. Fix<y>? yes Pass 5: Checking group summary information Block bitmap differences: -(208264--208266) -(210062--210068) -(211343--211491) -(213241--213250) -(213344--213393) -213397 -(213457--213463) -(213516--213521) -(213628--213655) -(213683--213688) -(213709--213728) -(215265--215300) -(215346--215365) -(221541--221551) -(221696--221704) -227517 Fix<y>? yes Free blocks count wrong for group #6 (17247, counted=17611). Fix<y>? yes Free blocks count wrong (161691, counted=162055). Fix<y>? yes Inode bitmap differences: +(47089--47090) +47093 +47095 +(47097--47099) +(47101--47104) -(47219--47220) -47222 -47224 -47228 -47231 -(47347--47348) -47350 -47352 -47356 -47359 -(47457--47488) -47985 -47996 -(47999--48000) -48017 -(48027--48028) -(48030--48032) -48049 -(48059--48060) -(48062--48064) -48081 -(48091--48092) -(48094--48096) Fix<y>? yes Free inodes count wrong for group #6 (7608, counted=7624). Fix<y>? yes Free inodes count wrong (61919, counted=61935). Fix<y>? yes embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED ***** embeddedrootwrite: ********** WARNING: Filesystem still has errors ********** embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks Embedded-PC-failsafe:~# Embedded-PC-failsafe:~# e2fsck /dev/sda3 e2fsck 1.41.3 (12-Oct-2008) embeddedrootwrite contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Directory entry for '.' in ... (46948) is big. Split<y>? yes Missing '..' in directory inode 46948. Fix<y>? yes Setting filetype for entry '..' in ... (46948) to 2. Pass 3: Checking directory connectivity '..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953). Fix<y>? yes Pass 4: Checking reference counts Inode 2 ref count is 12, should be 13. Fix<y>? yes Pass 5: Checking group summary information embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED ***** embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks Embedded-PC-failsafe:~# Embedded-PC-failsafe:~# e2fsck /dev/sda3 e2fsck 1.41.3 (12-Oct-2008) embeddedrootwrite: clean, 657/62592 files, 87882/249937 blocks

    Read the article

  • Inode to device information

    - by Methos
    I have 3 questions: I want to figure out if a file belongs to a USB device given the file inode. By looking in the latest kernel sources (2.6.33) on LXR, I think one can find that information by following pointers as follows: inode-super_block-block_device-backing_dev_info-device-device_driver(or device_type). However, the kernel that I am working with - 2.6.22.14 - does not have struct device pointer in the backing_dev_info object. So how can I figure out to which device does a file belong to from just the inode? I see that each of the inode, super_block and block_device contain an object of type 'dev_t'. But even after searching a lot, I could not find out how to convert 'dev_t' into struct device *. Is there any way to get that infomation? I tried to print device major and minor numbers using imajor(inode) and iminor(inode). However, for every file - belonging to hdd or usb - it always prints major and minor number as zero. Why would that be happening? I searched online for USB major numbers and I found out that major number for a USB is 180. However, on multiple machines, it showed me the major number associated with the USB dev as 253. $ ls -ltr /dev/usb* crw-rw---- 1 root root 253, 4 2010-04-13 17:20 /dev/usbmon4 crw-rw---- 1 root root 253, 3 2010-04-13 17:20 /dev/usbmon3 crw-rw---- 1 root root 253, 8 2010-04-13 17:20 /dev/usbmon8 crw-rw---- 1 root root 253, 5 2010-04-13 17:20 /dev/usbmon5 crw-rw---- 1 root root 253, 1 2010-04-13 17:20 /dev/usbmon1 crw-rw---- 1 root root 253, 7 2010-04-13 17:20 /dev/usbmon7 Why is that so?

    Read the article

  • URL shortening: using inode as short name?

    - by Licky Lindsay
    The site I am working on wants to generate its own shortened URLs rather than rely on a third party like tinyurl or bit.ly. Obviously I could keep a running count new URLs as they are added to the site and use that to generate the short URLs. But I am trying to avoid that if possible since it seems like a lot of work just to make this one thing work. As the things that need short URLs are all real physical files on the webserver my current solution is to use their inode numbers as those are already generated for me ready to use and guaranteed to be unique. function short_name($file) { $ino = @fileinode($file); $s = base_convert($ino, 10, 36); return $s; } This seems to work. Question is, what can I do to make the short URL even shorter? On the system where this is being used, the inodes for newly added files are in a range that makes the function above return a string 7 characters long. Can I safely throw away some (half?) of the bits of the inode? And if so, should it be the high bits or the low bits? I thought of using the crc32 of the filename, but that actually makes my short names longer than using the inode. Would something like this have any risk of collisions? I've been able to get down to single digits by picking the right value of "$referencefile". function short_name($file) { $ino = @fileinode($file); // arbitrarily selected pre-existing file, // as all newer files will have higher inodes $ino = $ino - @fileinode($referencefile); $s = base_convert($ino, 10, 36); return $s; }

    Read the article

  • Recovering from apt-get upgrade gone wrong due to a full disk

    - by Peter
    I was performing an apt-get upgrade on an Ubuntu 12.04.5 LTS box that hadn't been updated in a little while and the upgrade failed due to 'No space left on device'. After a little while I worked out space meant inodes and I have freed some up but unfortunately things have been left something askew. I have tried manually installing the old versions of packages mentioned using dpkg -i but that doesn't help. I have tried apt-get upgrade and apt-get -f install to no avail. Results are below. Any ideas how to fix things up? FIXED: Installing the earlier versions again manually via dpkg -i and then apt-get -f install has done the trick. Not sure why this didn't work the first time. The packages in question are listed below but they will presumably vary. libssl1.0.0_1.0.1-4ubuntu5.14_i386.deb linux-headers-3.2.0-64-generic-pae_3.2.0-64.97_i386.deb linux-image-generic-pae_3.2.0.64.76_i386.deb linux-headers-3.2.0-64_3.2.0-64.97_all.deb linux-headers-generic-pae_3.2.0.64.76_i386.deb root@unlinked:/tmp# apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done You might want to run ‘apt-get -f install’ to correct these. The following packages have unmet dependencies. libssl-dev : Depends: libssl1.0.0 (= 1.0.1-4ubuntu5.14) but 1.0.1-4ubuntu5.17 is installed linux-generic-pae : Depends: linux-image-generic-pae (= 3.2.0.64.76) but 3.2.0.67.79 is installed Depends: linux-headers-generic-pae (= 3.2.0.64.76) but 3.2.0.67.79 is installed E: Unmet dependencies. Try using -f. root@unlinked:/tmp# apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following packages were automatically installed and are no longer required: linux-headers-3.2.0-43-generic-pae linux-headers-3.2.0-38-generic-pae linux-headers-3.2.0-41-generic-pae linux-headers-3.2.0-36-generic-pae linux-headers-3.2.0-63-generic-pae linux-headers-3.2.0-58-generic-pae linux-headers-3.2.0-60-generic-pae linux-headers-3.2.0-55-generic-pae linux-headers-3.2.0-40 linux-headers-3.2.0-41 linux-headers-3.2.0-36 linux-headers-3.2.0-37 linux-headers-3.2.0-43 linux-headers-3.2.0-38 linux-headers-3.2.0-44 linux-headers-3.2.0-39 linux-headers-3.2.0-45 linux-headers-3.2.0-51 linux-headers-3.2.0-52 linux-headers-3.2.0-53 linux-headers-3.2.0-48 linux-headers-3.2.0-54 linux-headers-3.2.0-60 linux-headers-3.2.0-55 linux-headers-3.2.0-61 linux-headers-3.2.0-56 linux-headers-3.2.0-57 linux-headers-3.2.0-63 linux-headers-3.2.0-58 linux-headers-3.2.0-59 linux-headers-3.2.0-52-generic-pae linux-headers-3.2.0-44-generic-pae linux-headers-3.2.0-39-generic-pae linux-headers-3.2.0-37-generic-pae linux-headers-3.2.0-59-generic-pae linux-headers-3.2.0-61-generic-pae linux-headers-3.2.0-56-generic-pae linux-headers-3.2.0-53-generic-pae linux-headers-3.2.0-48-generic-pae linux-headers-3.2.0-45-generic-pae linux-headers-3.2.0-40-generic-pae linux-headers-3.2.0-57-generic-pae linux-headers-3.2.0-54-generic-pae linux-headers-3.2.0-51-generic-pae Use 'apt-get autoremove' to remove them. The following extra packages will be installed: libssl-dev linux-generic-pae The following packages will be upgraded: libssl-dev linux-generic-pae 2 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade. 2 not fully installed or removed. Need to get 0 B/1,427 kB of archives. After this operation, 1,024 B of additional disk space will be used. Do you want to continue [Y/n]? y dpkg: dependency problems prevent configuration of libssl-dev: libssl-dev depends on libssl1.0.0 (= 1.0.1-4ubuntu5.14); however: Version of libssl1.0.0 on system is 1.0.1-4ubuntu5.17. dpkg: error processing libssl-dev (--configure): dependency problems - leaving unconfigured No apport report written because the error message indicates it's a follow-up error from a previous failure. dpkg: dependency problems prevent configuration of linux-generic-pae: linux-generic-pae depends on linux-image-generic-pae (= 3.2.0.64.76); however: Version of linux-image-generic-pae on system is 3.2.0.67.79. linux-generic-pae depends on linux-headers-generic-pae (= 3.2.0.64.76); however: Version of linux-headers-generic-pae on system is 3.2.0.67.79. dpkg: error processing linux-generic-pae (--configure): dependency problems - leaving unconfigured No apport report written because the error message indicates it's a follow-up error from a previous failure. Errors were encountered while processing: libssl-dev linux-generic-pae E: Sub-process /usr/bin/dpkg returned an error code (1)

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

1 2 3 4 5 6 7 8  | Next Page >