[opensuse] convert a folder into a block device
Can I make /home a partition? Without repartitioning? If someone can reply with an acronym, I think I've got it. But the documentation doesn't make it easy. Thanks, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn wrote:
Can I make /home a partition? Without repartitioning? If someone can reply with an acronym, I think I've got it. But the documentation doesn't make it easy.
If you have a spare partition, you could copy /home over there and mount that. -- Per Jessen, Zürich (18.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2014-07-02 at 11:25 +0200, Per Jessen wrote:
lynn wrote:
Can I make /home a partition? Without repartitioning? If someone can reply with an acronym, I think I've got it. But the documentation doesn't make it easy.
If you have a spare partition, you could copy /home over there and mount that.
No, the whole disk is one partition:( -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/07/2014 11:50, lynn a écrit :
Can I make /home a partition? Without repartitioning? If someone can
No, the whole disk is one partition:(
so what do you mean by "make a home partition"? make a partition *is* partitionning. you can reduce the present partition from a live dvd and create an other for /home, but all is some sort of repartitionning jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2014-07-02 at 11:55 +0200, jdd wrote:
Le 02/07/2014 11:50, lynn a écrit :
Can I make /home a partition? Without repartitioning? If someone can
No, the whole disk is one partition:(
so what do you mean by "make a home partition"?
Almost, '...make /home a partition...'.
you can reduce the present partition from a live dvd and create an other for /home, but all is some sort of repartitionning
OK L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/02/2014 11:50 AM, lynn wrote:
On Wed, 2014-07-02 at 11:25 +0200, Per Jessen wrote:
lynn wrote:
Can I make /home a partition? Without repartitioning? If someone can reply with an acronym, I think I've got it. But the documentation doesn't make it easy.
If you have a spare partition, you could copy /home over there and mount that.
No, the whole disk is one partition:(
You could create a file system in a (huge) file [1][2], loop-mount it somewhere [3], move /home/* to there [4], umount it [5], and mount it (still with -o loop) on /home [6]. [0] export IMG="/somewhere/home.img" [1] dd if=/dev/zero of=$IMG bs=1G count=100 [2] /sbin/mkfs.ext4 -F $IMG /mnt [3] mount -o loop $IMG /mnt [4] mv /home/* /mnt [5] umount /mnt [6] mount -o loop $IMG /home Notes: a) Loop-mounting is of course a bit slower than a native disk. b) The sizes of the dd(1) command above may need to be adjusted. c) The mv(1) command above may have to be tweaked to match all directories there (or for omitting lost+found). d) You'd have to adapt /etc/fstab to mount /home automatically on boot. You didn't tell why you want /home on a separate file system, so I can't judge if the above suffices your needs. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2014-07-02 at 12:34 +0200, Bernhard Voelker wrote:
On 07/02/2014 11:50 AM, lynn wrote:
On Wed, 2014-07-02 at 11:25 +0200, Per Jessen wrote:
lynn wrote:
Can I make /home a partition? Without repartitioning? If someone can reply with an acronym, I think I've got it. But the documentation doesn't make it easy.
If you have a spare partition, you could copy /home over there and mount that.
No, the whole disk is one partition:(
You could create a file system in a (huge) file [1][2], loop-mount it somewhere [3], move /home/* to there [4], umount it [5], and mount it (still with -o loop) on /home [6].
[0] export IMG="/somewhere/home.img" [1] dd if=/dev/zero of=$IMG bs=1G count=100 [2] /sbin/mkfs.ext4 -F $IMG /mnt [3] mount -o loop $IMG /mnt [4] mv /home/* /mnt [5] umount /mnt [6] mount -o loop $IMG /home
Notes: a) Loop-mounting is of course a bit slower than a native disk. b) The sizes of the dd(1) command above may need to be adjusted. c) The mv(1) command above may have to be tweaked to match all directories there (or for omitting lost+found). d) You'd have to adapt /etc/fstab to mount /home automatically on boot.
You didn't tell why you want /home on a separate file system, so I can't judge if the above suffices your needs.
No, sorry. I have, for my sins, to get some sort of failover for our domain file server. Having failed so badly with dfs, I'm going to try drdb. The test boxes I have have the sync data in /home but /home is a folder. Your loop mount is looking good. Does it count as a drdb block device thingy? Thanks, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On July 2, 2014 6:48:10 AM EDT, lynn <lynn@steve-ss.com> wrote:
On Wed, 2014-07-02 at 12:34 +0200, Bernhard Voelker wrote:
On 07/02/2014 11:50 AM, lynn wrote:
On Wed, 2014-07-02 at 11:25 +0200, Per Jessen wrote:
lynn wrote:
Can I make /home a partition? Without repartitioning? If someone can reply with an acronym, I think I've got it. But the documentation doesn't make it easy.
If you have a spare partition, you could copy /home over there and mount that.
No, the whole disk is one partition:(
You could create a file system in a (huge) file [1][2], loop-mount it somewhere [3], move /home/* to there [4], umount it [5], and mount it (still with -o loop) on /home [6].
[0] export IMG="/somewhere/home.img" [1] dd if=/dev/zero of=$IMG bs=1G count=100 [2] /sbin/mkfs.ext4 -F $IMG /mnt [3] mount -o loop $IMG /mnt [4] mv /home/* /mnt [5] umount /mnt [6] mount -o loop $IMG /home
Notes: a) Loop-mounting is of course a bit slower than a native disk. b) The sizes of the dd(1) command above may need to be adjusted. c) The mv(1) command above may have to be tweaked to match all directories there (or for omitting lost+found). d) You'd have to adapt /etc/fstab to mount /home automatically on boot.
You didn't tell why you want /home on a separate file system, so I can't judge if the above suffices your needs.
No, sorry. I have, for my sins, to get some sort of failover for our domain file server. Having failed so badly with dfs, I'm going to try drdb. The test boxes I have have the sync data in /home but /home is a folder. Your loop mount is looking good. Does it count as a drdb block device thingy? Thanks, L x
Drdb? I assume you mean drbd? Distributed - replicated- block device I think a loop mount will work for that, but it may fail your testing where real disks / partitions / logical volumes would pass. See http://lists.linbit.com/pipermail/drbd-user/2011-May/016009.html which ends with a statement not o do it. If this is for testing only why not hook up a second drive for a while. Sata / eSata / usb3 would all work fine I would think. Sata / eSata run faster, but you can get almost 100 MB / sec out of usb3. I have a laptop with 2 usb3 ports. One ran 20% faster than the other on a recent simultaneous test. (Md5sum of 500 GB of identical data on both disks.) Anyway, don't assume all usb3 ports are the same speed. You could also consider iscsi but you might hit issues with that you would not have with physical disks, especially if you have a high i/o load during the testing. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2014-07-02 at 08:09 -0400, Greg Freemyer wrote:
On July 2, 2014 6:48:10 AM EDT, lynn <lynn@steve-ss.com> wrote:
On Wed, 2014-07-02 at 12:34 +0200, Bernhard Voelker wrote:
On 07/02/2014 11:50 AM, lynn wrote:
On Wed, 2014-07-02 at 11:25 +0200, Per Jessen wrote:
lynn wrote:
Can I make /home a partition? Without repartitioning? If someone can reply with an acronym, I think I've got it. But the documentation doesn't make it easy.
If you have a spare partition, you could copy /home over there and mount that.
No, the whole disk is one partition:(
You could create a file system in a (huge) file [1][2], loop-mount it somewhere [3], move /home/* to there [4], umount it [5], and mount it (still with -o loop) on /home [6].
[0] export IMG="/somewhere/home.img" [1] dd if=/dev/zero of=$IMG bs=1G count=100 [2] /sbin/mkfs.ext4 -F $IMG /mnt [3] mount -o loop $IMG /mnt [4] mv /home/* /mnt [5] umount /mnt [6] mount -o loop $IMG /home
Notes: a) Loop-mounting is of course a bit slower than a native disk. b) The sizes of the dd(1) command above may need to be adjusted. c) The mv(1) command above may have to be tweaked to match all directories there (or for omitting lost+found). d) You'd have to adapt /etc/fstab to mount /home automatically on boot.
You didn't tell why you want /home on a separate file system, so I can't judge if the above suffices your needs.
No, sorry. I have, for my sins, to get some sort of failover for our domain file server. Having failed so badly with dfs, I'm going to try drdb. The test boxes I have have the sync data in /home but /home is a folder. Your loop mount is looking good. Does it count as a drdb block device thingy? Thanks, L x
Drdb? I assume you mean drbd? Distributed - replicated- block device
My superior suggested 'drdb' (sic). Thank you so much for this comment.
I think a loop mount will work for that, but it may fail your testing where real disks / partitions / logical volumes would pass.
It seems that yast has a tool to resize partitions. I wonder how reliable that is? I just tried booting a vm with kde. Resized it. Lost everything. Maybe it just doesn't work for vms. Thanks again, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/02/2014 01:03 PM, Carlos E. R. wrote:
On 2014-07-02 12:34, Bernhard Voelker wrote:
a) Loop-mounting is of course a bit slower than a native disk.
I think I read this was no longer the case. :-?
I don't have numbers, but a loop-mount is just another level of indirection via the file system the backing file is stored in. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-02 13:18, Bernhard Voelker wrote:
On 07/02/2014 01:03 PM, Carlos E. R. wrote:
On 2014-07-02 12:34, Bernhard Voelker wrote:
a) Loop-mounting is of course a bit slower than a native disk.
I think I read this was no longer the case. :-?
I don't have numbers, but a loop-mount is just another level of indirection via the file system the backing file is stored in.
I know. But, in theory, an operating system can create a table of the sectors used by the loop file, and use that table instead of calling the filesystem libs to access the file. The file itself is static, it doesn't change in size nor location, at least while mounted: thus you really do not need to access the filesytem structures. If the file is not fragmented, then it should be as fast as a real partition. This technique is used for swap files. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 07/02/2014 01:31 PM, Carlos E. R. wrote:
But, in theory, an operating system can create a table of the sectors used by the loop file, and use that table instead of calling the filesystem libs to access the file. The file itself is static, it doesn't change in size nor location, at least while mounted: thus you really do not need to access the filesytem structures.
If the file is not fragmented, then it should be as fast as a real partition.
That's a nice trick. I'd guess that it doesn't work with all file system types, as this assumes that the underlying file system doesn't somehow move the data along. I'm unsure if any does, but e.g. via - I know, a bad choice - NFS, the loop module couldn't rely on this assumption. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/07/2014 15:29, Bernhard Voelker a écrit :
That's a nice trick. I'd guess that it doesn't work with all file system types, as this assumes that the underlying file system doesn't somehow move the data along. I'm unsure if any does, but e.g. via - I know, a bad choice - NFS, the loop module couldn't rely on this assumption.
you can have any linux filesystem on loop device, but you need to create at first the file with the total size, wich is not bery practical for hudge partitions jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 02/07/2014 15:29, Bernhard Voelker a écrit :
That's a nice trick. I'd guess that it doesn't work with all file system types, as this assumes that the underlying file system doesn't somehow move the data along. I'm unsure if any does, but e.g. via - I know, a bad choice - NFS, the loop module couldn't rely on this assumption.
you can have any linux filesystem on loop device, but you need to create at first the file with the total size, wich is not bery practical for hudge partitions
Maybe you could use "truncate" to create a sparse file? -- Per Jessen, Zürich (18.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-02 16:37, Per Jessen wrote:
jdd wrote:
Le 02/07/2014 15:29, Bernhard Voelker a écrit :
That's a nice trick. I'd guess that it doesn't work with all file system types, as this assumes that the underlying file system doesn't somehow move the data along. I'm unsure if any does, but e.g. via - I know, a bad choice - NFS, the loop module couldn't rely on this assumption.
you can have any linux filesystem on loop device, but you need to create at first the file with the total size, wich is not bery practical for hudge partitions
Maybe you could use "truncate" to create a sparse file?
In theory, yes. I believe that vmware uses that trick for its virtual disks. But I also believe that it makes access slower, because the file can not be mapped for fast access, or not that easily. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-07-02 15:29, Bernhard Voelker wrote:
On 07/02/2014 01:31 PM, Carlos E. R. wrote:
But, in theory, an operating system can create a table of the sectors used by the loop file, and use that table instead of calling the filesystem libs to access the file. The file itself is static, it doesn't change in size nor location, at least while mounted: thus you really do not need to access the filesytem structures.
If the file is not fragmented, then it should be as fast as a real partition.
That's a nice trick.
Please remember that mine is an educated guess. I /did/ read that swap files are as fast as a real partition, since some version, and I /think/ I read that it also applies to loop files. I don't have confirmation on those, but, based on the theory above, I believe they do. I would have to test it, though.
I'd guess that it doesn't work with all file system types, as this assumes that the underlying file system doesn't somehow move the data along. I'm unsure if any does, but e.g. via - I know, a bad choice - NFS, the loop module couldn't rely on this assumption.
I suppose that the module can find that out. It is all part of the kernel, so if they decide to add that facility, they can add the needed features everywhere as needed :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 07/02/2014 07:31 AM, Carlos E. R. wrote:
If the file is not fragmented, then it should be as fast as a real partition.
How often are files fragmented? I thought the file systems used in Linux were fragmentation resistant. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-02 16:12, James Knott wrote:
On 07/02/2014 07:31 AM, Carlos E. R. wrote:
If the file is not fragmented, then it should be as fast as a real partition.
How often are files fragmented? I thought the file systems used in Linux were fragmentation resistant.
Resistant, yes, but not immune. fsck tells you the amount. I have seen Linux machines heavily fragmented. Look: nimrodel:~ # fsck /dev/sdb1 fsck 1.40.8 (13-Mar-2008) e2fsck 1.40.8 (13-Mar-2008) Moria_250 has been mounted 1574 times without being checked, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 3A: Optimizing directories Pass 4: Checking reference counts Pass 5: Checking group summary information Moria_250: ***** FILE SYSTEM WAS MODIFIED ***** Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960 blocks nimrodel:~ # See that 62.6%? That's heavy fragmentation. The disk belongs to a multimedia device that runs Linux (kernel 2.4.21), on an ext2 partition. To totally avoid fragmentation, you have to assign the full space for each file at the instant of creation, and separate files one from another sufficiently so that they can grow. When the disk gets quite filled, the strategy fails. It is possible to move about files while the system is running, if designed carefully. The easiest is to move unused files on iddle system periods - but I don't know of any operating system doing it. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Wed, Jul 2, 2014 at 11:15 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2014-07-02 16:12, James Knott wrote:
On 07/02/2014 07:31 AM, Carlos E. R. wrote:
If the file is not fragmented, then it should be as fast as a real partition.
How often are files fragmented? I thought the file systems used in Linux were fragmentation resistant.
Resistant, yes, but not immune. fsck tells you the amount. I have seen Linux machines heavily fragmented. Look:
ext4 uses a max of 128 MB block extensions. For large files that are pre-allocated the individual block extensions should be the full 128 MB if possible. It is unlikely all the block extensions will be contiguous from what I understand. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2014-07-02 at 11:57 -0400, Greg Freemyer wrote:
On Wed, Jul 2, 2014 at 11:15 AM, Carlos E. R. <> wrote:
Resistant, yes, but not immune. fsck tells you the amount. I have seen Linux machines heavily fragmented. Look:
ext4 uses a max of 128 MB block extensions. For large files that are pre-allocated the individual block extensions should be the full 128 MB if possible. It is unlikely all the block extensions will be contiguous from what I understand.
In that particular example, most of the files are 65 MB, with matching index files of about 3 to 5 KB, on an external disk via USB, and it is ext2 (not 2 nor 4, and not a choice; the alternative is FAT). It is a multimedia box of limited cpu power. I just gave it as an example of a machine where heavy fragmentation occurs. On normal Linux machines, the percent is about 2, IIRC. For instance: Telcontar:~ # fsck -f /dev/sdc9 fsck from util-linux 2.23.2 e2fsck 1.42.8 (20-Jun-2013) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information a_test2: 230470/1313280 files (0.1% non-contiguous), 3297636/5242880 blocks Telcontar:~ # - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO1J2kACgkQtTMYHG2NR9XhpACfasIw+gOv6dcT5AxlYrLZHe4d bJUAn2Q+W5dst8imB/0VyDQ3/bITYOx7 =sI1+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Jul 2, 2014 at 11:15 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
To totally avoid fragmentation, you have to assign the full space for each file at the instant of creation, and separate files one from another sufficiently so that they can grow. When the disk gets quite filled, the strategy fails. It is possible to move about files while the system is running, if designed carefully. The easiest is to move unused files on iddle system periods - but I don't know of any operating system doing it.
I'm not quite sure what you're saying. e4defrag will defrag an extent based filesystem (as opposed to a block based filesystem like ext2). It does it with the filesystem online. Several years ago I had studied the code and as I recall for a non-sparse file it calls fallocate to allocate a new file of the same size, then compares the number of extents in the original and new file. If the number of extents is less in the new file, it moves the blocks from the old locations to the new ones. The move is handled in the kernel directly so the locking is pretty granular as I recall. It wasn't extremely robust 4 or 5 years ago, but I assume the bugs have been worked out by now and it is safe to call it via cron as desired. Admittedly, I haven't used it much myself. I was evaluating the code base for a different use case. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2014-07-02 at 12:03 -0400, Greg Freemyer wrote:
On Wed, Jul 2, 2014 at 11:15 AM, Carlos E. R. <> wrote:
To totally avoid fragmentation, you have to assign the full space for each file at the instant of creation, and separate files one from another sufficiently so that they can grow. When the disk gets quite filled, the strategy fails. It is possible to move about files while the system is running, if designed carefully. The easiest is to move unused files on iddle system periods - but I don't know of any operating system doing it.
I'm not quite sure what you're saying. e4defrag will defrag an extent based filesystem (as opposed to a block based filesystem like ext2). It does it with the filesystem online.
Ah, that's good news :-) Progress :-) - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO1KI0ACgkQtTMYHG2NR9XtDQCeNxxfNQCXbjMalZ5rv68tuh96 3O8AnRYY3/fHkrXMOG5ew1CoHufrbQ5r =lOgB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Jul 2, 2014 at 12:03 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Wed, Jul 2, 2014 at 11:15 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
To totally avoid fragmentation, you have to assign the full space for each file at the instant of creation, and separate files one from another sufficiently so that they can grow. When the disk gets quite filled, the strategy fails. It is possible to move about files while the system is running, if designed carefully. The easiest is to move unused files on iddle system periods - but I don't know of any operating system doing it.
I'm not quite sure what you're saying. e4defrag will defrag an extent based filesystem (as opposed to a block based filesystem like ext2). It does it with the filesystem online.
Carlos, You may find it interesting that there is the beginnings of an effort to create e4defrag2. http://lists.openwall.net/linux-ext4/2014/04/28/3 I came across it because I saw this post where the same author is discussing some of his needs: http://markmail.org/message/vywin7l35krhq7vd If you google for IOC_MOV_DATA you will see someone has proposed a new ioctl that is similar to the one ext4 uses with e4defrag. I think that is good so that e4defrags underlying kernel code can get more use/testing. http://markmail.org/message/uypupmfcouasfeou Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bernhard Voelker <mail@bernhard-voelker.de> writes:
You could create a file system in a (huge) file [1][2], loop-mount it somewhere [3], move /home/* to there [4], umount it [5], and mount it (still with -o loop) on /home [6].
[0] export IMG="/somewhere/home.img" [1] dd if=/dev/zero of=$IMG bs=1G count=100 [2] /sbin/mkfs.ext4 -F $IMG /mnt [3] mount -o loop $IMG /mnt [4] mv /home/* /mnt [5] umount /mnt [6] mount -o loop $IMG /home
The "loop" kernel module also must be loaded- it is no longer loaded by default. To have it automatically loaded at boot time, one can put: ,---- | loop `---- in /etc/modules-load.d/local.conf. Charles -- "On a normal ascii line, the only safe condition to detect is a 'BREAK' - everything else having been assigned functions by Gnu EMACS." (By Tarl Neustaedter)
a solution, may be, could be to use a btrfs filessyetem and manage internal separation for /home but I never tried this so don't know if it works http://fr.wikipedia.org/wiki/Btrfs jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/07/14 13:15, jdd wrote:
a solution, may be, could be to use a btrfs filessyetem and manage internal separation for /home
but I never tried this so don't know if it works
http://fr.wikipedia.org/wiki/Btrfs
jdd
btrfs comes with lots of warnings that it is experimental. Nevertheless, I am trying it out here, and have not had any problems yet. ;-) You can convert an existing ext3/4 filesystem to btrfs: # btrfs-convert /dev/sdx The existing data is stored in /ext2_saved which can be deleted once you are happy with running a btrfs system. This folder is there in case you want to revert back to extfs. Once you delete it, you've burnt your bridges... Then rename /home to eg. /home_old Create a newsubvolume: btrfs subvolume create /home Copy/move the contents of /home_old into /home Delete /home_old *** Disclaimer: I am an amateur/hobbyist whiling away my retirement, and cannot vouch that the above procedure is failsafe. It _has_ worked several times without failure (yet) here. *** Bob - -- Bob Williams System: Linux 3.11.10-17-desktop Distro: openSUSE 13.1 (x86_64) with KDE Development Platform: 4.13.2 Uptime: 06:00am up 3 days 20:14, 5 users, load average: 0.08, 0.04, 0.05 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO0H18ACgkQ0Sr7eZJrmU7DSACfZ6UWzCVGPovx/vhEvzIsLKtt UkMAniAh/c+qsMnfpW4qAG3ehN5dYCrg =IUjW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/02/2014 05:50 AM, lynn wrote:
No, the whole disk is one partition:(
Including swap? If you can't resize the existing partition to make room for a /home partition, then just add a drive and use it, as I mentioned earlier. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/02/2014 05:15 AM, lynn wrote:
Can I make /home a partition? Without repartitioning? If someone can reply with an acronym, I think I've got it. But the documentation doesn't make it easy.
You will need a partition. If you haven't got one free, you'll have to create one. One possibility is to add a drive and put home there. Just mount the partition on a temporary mount point and move all the stuff from /home there, then remount it on /home. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Bernhard Voelker -
Bob Williams -
Carlos E. R. -
Charles Philip Chan -
Greg Freemyer -
James Knott -
jdd -
lynn -
Per Jessen