Re: compatible filesystems between Mac and Linux

On Mon, 2024-07-29 at 22:01 +0930, Tim via users wrote: > I went with EXFAT. I had tried various other filing systems in the past, but both sides have to support it well. Sometimes you'd find both sides could read something okay, but messed up when creating files in a way that required a disc rep

Re: compatible filesystems between Mac and Linux

On Wed, 2024-07-31 at 08:48 -0300, George N. White III wrote: > I've been retired for years, but worked in a group that replaced SGI > IRIX4 with macOS. We used EXFAT on external drives. We had > colleagues scattered around the globe, so there were often problems > with filenames using unicode, i

Re: compatible filesystems between Mac and Linux

Jeffrey Walton : > > One other thing... Apple also provides support for multiple-forks, > > which are like NTFS Alternate Data Streams. So be sure to avoid them > > on the Apple side. Also see . Barry: > I do not see this in macOS these days. It’s a hang ov

Re: compatible filesystems between Mac and Linux

> On 31 Jul 2024, at 13:08, Jeffrey Walton wrote: > > One other thing... Apple also provides support for multiple-forks, > which are like NTFS Alternate Data Streams. So be sure to avoid them > on the Apple side. Also see . I do not see this in macOS th

Re: compatible filesystems between Mac and Linux

On Mon, Jul 29, 2024 at 3:05 AM Jeffrey Walton wrote: > > On Mon, Jul 29, 2024 at 1:32 AM Tim via users > wrote: > > > > If I wanted to use a USB hard drive between a Mac and Linux, what are > > the best choices of file systems that work well in both ways? > > > > Chiefly, I'm offloading edited v

Re: compatible filesystems between Mac and Linux

On Mon, Jul 29, 2024 at 9:32 AM Tim via users wrote: > Tim: > > > If I wanted to use a USB hard drive between a Mac and Linux, what are > > > the best choices of file systems that work well in both ways? > > > > > > Chiefly, I'm offloading edited video files from the Mac's drive that's > > > fill

Re: compatible filesystems between Mac and Linux

Linux has drivers for mac;s hfs filesystem. I have used those before with no difficulty. On Mon, 29 Jul 2024 15:01:49 +0930 Tim wrote: Hi, If I wanted to use a USB hard drive between a Mac and Linux, what are the best choices of file systems that work well in both ways? Chiefly, I'm offloa

Re: compatible filesystems between Mac and Linux

On Mon, 2024-07-29 at 11:00 +0100, Patrick O'Callaghan wrote: > Also, be aware that some Apple filesystems allow hard links to > directories (to support Time Machine). May or may not be relevant. I don't use that. -- uname -rsvp Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tu

Re: compatible filesystems between Mac and Linux

om/guide/disk-utility/file-system-formats-dsku19ed921c/mac>. I remember trying to read some Apple filesystems on Linux in the past, and having some grief about read/write compatibility. Though so long ago I don't recall what problems, and which file system. > But be careful of character sets

Re: compatible filesystems between Mac and Linux

Tim: > > If I wanted to use a USB hard drive between a Mac and Linux, what are > > the best choices of file systems that work well in both ways? > > > > Chiefly, I'm offloading edited video files from the Mac's drive that's > > filling up, that I want to keep for posterity. But it would be nice t

Re: compatible filesystems between Mac and Linux

Mac charset for filenames, and the gunlib folks don't approve > of > Apple's modifications. So there's a potential for filename problems. > Also see <https://github.com/fumiyas/libiconv-utf8mac>. Also, be aware that some Apple filesystems allow hard links to directo

Re: compatible filesystems between Mac and Linux

On Mon, Jul 29, 2024 at 1:32 AM Tim via users wrote: > > If I wanted to use a USB hard drive between a Mac and Linux, what are > the best choices of file systems that work well in both ways? > > Chiefly, I'm offloading edited video files from the Mac's drive that's > filling up, that I want to kee

Re: compatible filesystems between Mac and Linux

On 7/28/24 10:31 PM, Tim via users wrote: If I wanted to use a USB hard drive between a Mac and Linux, what are the best choices of file systems that work well in both ways? Chiefly, I'm offloading edited video files from the Mac's drive that's filling up, that I want to keep for posterity. But

compatible filesystems between Mac and Linux

Hi, If I wanted to use a USB hard drive between a Mac and Linux, what are the best choices of file systems that work well in both ways? Chiefly, I'm offloading edited video files from the Mac's drive that's filling up, that I want to keep for posterity. But it would be nice to be able to read an

Re: Filesystems

On 09/07/2021 00:26, Patrick O'Callaghan wrote: On Thu, 2021-07-08 at 17:32 +0200, GianPiero Puccioni wrote: Thanks, I'll see what Fedora installer suggests. As for the compatibility I chose a Dell that could come with Ubuntu so I hope it will be a good choice,even if I got the Win version for o

Re: Filesystems

On Thu, 2021-07-08 at 17:32 +0200, GianPiero Puccioni wrote: > Thanks, I'll see what Fedora installer suggests. As for the > compatibility I > chose a Dell that could come with Ubuntu so I hope it will be a good > choice,even > if I got the Win version for other reasons. The F34 Workstation defa

Re: Filesystems

On 7/8/21 4:18 PM, George N. White III wrote: On Thu, 8 Jul 2021 at 05:29, GianPiero Puccioni > wrote: I am waiting for delivery of my new laptop, and it comes with SSD, is there a "better" filesystem for SSD (or in general). Unless you have a spe

Re: Filesystems

On Thu, 8 Jul 2021 at 05:29, GianPiero Puccioni < gianpiero.pucci...@isc.cnr.it> wrote: > I am waiting for delivery of my new laptop, and it comes with SSD, is > there a > "better" filesystem for SSD (or in general). > Unless you have a special use case or are installing an old version of Fedora,

Filesystems

Hi, I am waiting for delivery of my new laptop, and it comes with SSD, is there a "better" filesystem for SSD (or in general). GiP ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject

Re: Can't mount XFS filesystems on Fedora 33

t it was running the old > kernel after the reboots until the 5.10.22 kernel "aged" out and was > removed from the system. I am surprised it comes up at all. > > > > > > > > One would have to know exactly what is and is not built into an initrd > by dracut.

Re: Can't mount XFS filesystems on Fedora 33

ed it comes up at all. > > > One would have to know exactly what is and is not built into an initrd by dracut. What is included will allow the node to boot and at least get the root filesystems mounted so it can change root into it, but may not be able to mount any filesystems wit

Re: Can't mount XFS filesystems on Fedora 33

I see what happened now. I had moved my /boot to a new partition but didn't purge the old partition. It turns out that even though it wasn't mounting the old partition grub is still pointing to it for the kernels and since the 5.10.22 is the latest kernel on that partition it is the one it is loadi

Re: Can't mount XFS filesystems on Fedora 33

Looking into the kernel deeper it appears that for some reason tit is trying to load modules from the 5.10 kernel instead of the 5.11 kernels that are installed. I also just realized that it reports that I am still running a 5.10 kernel even though I don't even have one installed. Wow, I must have

Re: Can't mount XFS filesystems on Fedora 33

[root@images backups]# uname -r 5.10.22-200.fc33.x86_64 [root@images backups]# lsmod | grep xfs [root@images backups]# modprobe xfs modprobe: FATAL: Module xfs not found in directory /lib/modules/5.10.22-200.fc33.x86_64 [root@images backups]# On Fri, Mar 26, 2021 at 12:39 PM Chris Murphy wrote:

Re: Can't mount XFS filesystems on Fedora 33

[root@images backups]# lsblk -f /dev/sdc NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT sdc └─sdc1 xfsc2619e30-3bea-4e1d-a7a1-2e72e37a96b2 On Fri, Mar 26, 2021 at 8:36 AM Jorge Fábregas wrote: > On 3/25/21 10:52 PM, Shawn Badger wrote: >

Re: Can't mount XFS filesystems on Fedora 33

What kernel version? i.e. uname -r At the time of the mount failure, what do you get for: $ lsmod | grep xfs xfs 1892352 0 $ dmesg | grep -i xfs [ 717.658384] SGI XFS with ACLs, security attributes, scrub, quota, no debug enabled I suspect you get neither of the above results.

Re: Can't mount XFS filesystems on Fedora 33

On 3/25/21 10:52 PM, Shawn Badger wrote: > Has anyone else seen this or know where to point me to get the issue > resolved? No, I haven't seen this. Can you share the output of "lsblk -f" ? Regards, Jorge ___ users mailing list -- users@lists.fedorapro

Can't mount XFS filesystems on Fedora 33

I have a 10TB drive that is formatted with XFS and it has been working fine for a number of years and 2 days ago I did an update and now I cannot mount it any longer. I get "unknown filesystem type 'xfs'." from mount all of a sudden after updates. xfs_repair can see the volume and shows it with no

Re: Fedora 19 - filesystems slow

On 02.07.2014 09:49, George R Goffe wrote: Hi, I have a Fedora 19 system with several large 2-4TB drives attached via USB-SATA docking stations. I'm seeing a problem whereby a specific filesystem that hasn't been accessed for some time and is REALLY slow to respond to initial requests. ls -al

Re: Fedora 19 - filesystems slow

On Jul 2, 2014, at 1:49 AM, George R Goffe wrote: > Hi, > > I have a Fedora 19 system with several large 2-4TB drives attached via > USB-SATA docking stations. > > I'm seeing a problem whereby a specific filesystem that hasn't been accessed > for some time and is REALLY slow to respond to in

Re: Fedora 19 - filesystems slow

On 02.07.2014, Rick Stevens wrote: > I don't know of a way to control either the size of the cache or its > retention period. It might be controllable via a sysctl, but I've never > tried to bugger things like that. Look at parameters which can control the kernels virtual memory management, e.g.

Re: Fedora 19 - filesystems slow

ce in the cache similar to the one for real memory. Do you know the developers or of a mailing list? The filesystem cache is controlled by the kernel and the filesystem modules. Part of RAM is reserved for caches and it's shared across all the mounted filesystems IIRC. If a filesystem goes "

Re: Fedora 19 - filesystems slow

Do you know the developers or of a mailing list? Again, thanks for your response. George... From: Rick Stevens To: George R Goffe ; Community support for Fedora users Sent: Wednesday, July 2, 2014 10:36 AM Subject: Re: Fedora 19 - filesystems slow On 07/0

Re: Fedora 19 - filesystems slow

On 07/02/2014 12:49 AM, George R Goffe issued this missive: Hi, I have a Fedora 19 system with several large 2-4TB drives attached via USB-SATA docking stations. I'm seeing a problem whereby a specific filesystem that hasn't been accessed for some time and is REALLY slow to respond to initial

Fedora 19 - filesystems slow (George R Goffe)

Hi, Thank you for the response. hdparm -B showed the APM settings at 128, even the system drive. I have reset them to 255 and verified that these settings are in place. I will report on the status of this tomorrow. Again, thanks for the response. George... -- users mailing list users@lists

Re: Fedora 19 - filesystems slow

On 02.07.2014, George R Goffe wrote: > I'm seeing a problem whereby a specific filesystem that hasn't been > accessed for some time and is REALLY slow to respond to initial > requests. Looks like there is some power management which puts the device to sleep/spin down. Try disabling that. Also h

Re: Fedora 19 - filesystems slow

On 07/02/14 15:49, George R Goffe wrote: > have a Fedora 19 system with several large 2-4TB drives attached via > USB-SATA docking stations. > > I'm seeing a problem whereby a specific filesystem that hasn't been accessed > for some time and is REALLY slow to respond to initial requests. ls -alt

Fedora 19 - filesystems slow

Hi, I have a Fedora 19 system with several large 2-4TB drives attached via USB-SATA docking stations. I'm seeing a problem whereby a specific filesystem that hasn't been accessed for some time and is REALLY slow to respond to initial requests. ls -alt for example takes a substantial bit of tim

Re: tune2fs -E hash_alg=half_md4: safe for existing filesystems?

y indexing, or by sorting and compressing directories for smaller directories, or for filesystems using traditional linear directories. signature.asc Description: OpenPGP digital signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https

Re: tune2fs -E hash_alg=half_md4: safe for existing filesystems?

Bryn M. Reeves wrote: On 01/09/2013 06:18 PM, Bill Davidsen wrote: I would try this on something you can afford to lose... I just don't see any more info on this than you did before asking. I am curious, since I Changing hash_alg on an existing file system sets the default hash algorithm for n

Re: tune2fs -E hash_alg=half_md4: safe for existing filesystems?

On 01/09/2013 06:18 PM, Bill Davidsen wrote: I would try this on something you can afford to lose... I just don't see any more info on this than you did before asking. I am curious, since I Changing hash_alg on an existing file system sets the default hash algorithm for newly created directori

Re: tune2fs -E hash_alg=half_md4: safe for existing filesystems?

Reindl Harald wrote: i have some older filesystems with Default directory hash: tea is change them to "half_md4" safe? tune2fs -E hash_alg=half_md4 /dev/sdc1 they are all created short before the following commit: http://git.whamcloud.com/?p=tools/e2fsprogs.git;a=commitdi

tune2fs -E hash_alg=half_md4: safe for existing filesystems?

i have some older filesystems with Default directory hash: tea is change them to "half_md4" safe? tune2fs -E hash_alg=half_md4 /dev/sdc1 they are all created short before the following commit: http://git.whamcloud.com/?p=tools/e2fsprogs.git;a=commitdi

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

Am 10.02.2012 16:14, schrieb Timothy Murphy: > Reindl Harald wrote: >> you are a simple desktop-user with your stuff >> in /home, if you are develop software and >> integrate workflows in a system for managment >> and so on /home does not interest you much > > I don't understand this. > Do you m

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

Reindl Harald wrote: >>> sorry, but permanently reinstall the OS is a windows-thing >>> and especially unnaceptable if all 6 months a new version >>> is available and you have to maintain 2, 5, 10, 20 machines >> >> I don't agree - at least if one has 2 or 5 machines to deal with. >> I always do

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

Am 10.02.2012 14:43, schrieb Timothy Murphy: > Reindl Harald wrote: > >> sorry, but permanently reinstall the OS is a windows-thing >> and especially unnaceptable if all 6 months a new version >> is available and you have to maintain 2, 5, 10, 20 machines > > I don't agree - at least if one has

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

Reindl Harald wrote: > sorry, but permanently reinstall the OS is a windows-thing > and especially unnaceptable if all 6 months a new version > is available and you have to maintain 2, 5, 10, 20 machines I don't agree - at least if one has 2 or 5 machines to deal with. I always do a fresh install

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

Am 10.02.2012 08:35, schrieb Joe Zeff: > On 02/09/2012 01:57 PM, Reindl Harald wrote: >> so tame one seocond and imagine how it should work >> copy all this files and maintain them twice with yum >> >> sorry, but this makes no sense at all > > Whoever said that the old versions were to be mainta

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 02/09/2012 01:57 PM, Reindl Harald wrote: so tame one seocond and imagine how it should work copy all this files and maintain them twice with yum sorry, but this makes no sense at all Whoever said that the old versions were to be maintained? My thought was that they might be sitting there

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 2/9/2012 9:16 PM, David wrote: Understood. As I said it appears, and I would expect, that a 'fresh install' does work with no problems. And I am not saying that the update path does not, or will not, work. Only that I did not have much success with it. And, as I recall, the 'problems' in the

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 2/9/2012 11:51 PM, Paul Allen Newell wrote: > On 2/9/2012 8:31 PM, David wrote: >> Paul, >> >> I have yet to see a fresh install of Rawhide or Fedora 17. The current >> nightly Rawhide build ISOs will not install at all, for me, for some >> reason, and there are no as of yet ISOs available of Fe

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 2/9/2012 8:31 PM, David wrote: Paul, I have yet to see a fresh install of Rawhide or Fedora 17. The current nightly Rawhide build ISOs will not install at all, for me, for some reason, and there are no as of yet ISOs available of Fedora 17 that I know of. I would expect the Fedora 17 install

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 2/9/2012 8:51 PM, Paul Allen Newell wrote: > On 2/9/2012 2:12 PM, David wrote: >> On 2/9/2012 1:30 PM, Joe Zeff wrote: >>> On 02/09/2012 10:00 AM, Paul Allen Newell wrote: David: Thanks for the link, I was unaware of this change for F17. >>> Yes indeed. When I read what was going

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

tall rather than an upgrade. I was only qualifying my opinion about "new/moved filesystems" in F17. Plus I don't think Windows has anything to do with the topic or what I said ... the closest one can get in the way of comparisons is "fresh install" versus "upgrade&qu

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

>> to have before start working >> > > Please note that I never advised that anyone else should do a fresh install > rather than an upgrade. I was only > qualifying my opinion about "new/moved filesystems" in F17. Plus I don't > think Windows has anything to do

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

ike windows - for me it takes TWO DAYS until a fresh installed machine has exactly the state i like/need to have before start working Please note that I never advised that anyone else should do a fresh install rather than an upgrade. I was only qualifying my opinion about "new/moved fi

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

Am 10.02.2012 02:51, schrieb Paul Allen Newell: > but for whatever reason my gut says that clean installs when F17 is released > will probably work (no bets on Rawhide as that is where the problems are > supposed to be discovered --- and notice I use the word "probably" and not > "definitely" (

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 2/9/2012 2:12 PM, David wrote: On 2/9/2012 1:30 PM, Joe Zeff wrote: On 02/09/2012 10:00 AM, Paul Allen Newell wrote: David: Thanks for the link, I was unaware of this change for F17. Yes indeed. When I read what was going to be done, my first thought was, "Dear Ghod in Heaven, *why?*" By

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 2/9/2012 1:30 PM, Joe Zeff wrote: > On 02/09/2012 10:00 AM, Paul Allen Newell wrote: >> David: >> >> Thanks for the link, I was unaware of this change for F17. > > Yes indeed. When I read what was going to be done, my first thought > was, "Dear Ghod in Heaven, *why?*" By the time I reached th

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On Thu, 09 Feb 2012 10:53:13 -0800 Joe Zeff wrote: > On 02/09/2012 10:34 AM, Frank Murphy wrote: > > On 09/02/12 18:30, Joe Zeff wrote: > > > > One question, though: will there be a way to > >> recover the disk space used by the now-redundant directories? > > > > Just 4 symlinks are left? > > >

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

Am 09.02.2012 20:50, schrieb Joe Zeff: > On 02/09/2012 11:04 AM, Reindl Harald wrote: >> you know the difference between MOVE and COPY? >> /usrmove != /usrcopy > > Of course I do. However, I've learned better than to assume that things like > this are named the way you think they > are. Just

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 02/09/2012 11:04 AM, Reindl Harald wrote: you know the difference between MOVE and COPY? /usrmove != /usrcopy Of course I do. However, I've learned better than to assume that things like this are named the way you think they are. Just because it's called usrmove doesn't mean that it coul

( Long Post)Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 09/02/12 18:53, Joe Zeff wrote: On 02/09/2012 10:34 AM, Frank Murphy wrote: On 09/02/12 18:30, Joe Zeff wrote: One question, though: will there be a way to recover the disk space used by the now-redundant directories? Just 4 symlinks are left? It wasn't clear to me if everything in the

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

Am 09.02.2012 19:55, schrieb Joe Zeff: > On 02/09/2012 10:35 AM, Reindl Harald wrote: >> which disk space? >> where does a symlink consume noticeable space? > > As I wrote in another message, I was under the impression that the original > directories would be kept somewhere as > a backup. Just

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 02/09/2012 10:35 AM, Reindl Harald wrote: which disk space? where does a symlink consume noticeable space? As I wrote in another message, I was under the impression that the original directories would be kept somewhere as a backup. Just assuming that all will always go well and nuking the

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 02/09/2012 10:34 AM, Frank Murphy wrote: On 09/02/12 18:30, Joe Zeff wrote: One question, though: will there be a way to recover the disk space used by the now-redundant directories? Just 4 symlinks are left? It wasn't clear to me if everything in the old directories was deleted or not

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

Am 09.02.2012 19:30, schrieb Joe Zeff: > On 02/09/2012 10:00 AM, Paul Allen Newell wrote: >> David: >> >> Thanks for the link, I was unaware of this change for F17. > > Yes indeed. When I read what was going to be done, my first thought was, > "Dear Ghod in Heaven, *why?*" By the > time I rea

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 09/02/12 18:30, Joe Zeff wrote: One question, though: will there be a way to recover the disk space used by the now-redundant directories? Just 4 symlinks are left? -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- users mailing list users@lists.fedoraproject.org To unsub

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 02/09/2012 10:00 AM, Paul Allen Newell wrote: David: Thanks for the link, I was unaware of this change for F17. Yes indeed. When I read what was going to be done, my first thought was, "Dear Ghod in Heaven, *why?*" By the time I reached the bottom of the page it all made sense. One que

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 2/9/2012 9:42 AM, David wrote: On 2/9/2012 1:29 AM, Paul Allen Newell wrote: On 2/8/2012 2:17 PM, David wrote: If you 'liked' Fedora 16 you will just 'love' the new/moved filesystem. :-) David: I'll take the bait ... can you tell me what "love" is in the future? The comment was not inten

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 2/9/2012 1:29 AM, Paul Allen Newell wrote: > On 2/8/2012 2:17 PM, David wrote: >> If you 'liked' Fedora 16 you will just 'love' the new/moved >> filesystem. :-) >> > David: > > I'll take the bait ... can you tell me what "love" is in the future? The comment was not intended to be "bait". :-)

Re: Yum and Fedora 16 -- focus on "new/moved filesystems"

On 2/8/2012 2:17 PM, David wrote: If you 'liked' Fedora 16 you will just 'love' the new/moved filesystem. :-) David: I'll take the bait ... can you tell me what "love" is in the future? Thanks, Paul -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription op

Advice from filesystems expert needed - PART2

I face the same problem with Ubuntu,Fedora and OpenSuSE.I have the 3 systems on three partitions. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guid

Re: Advice from filesystems expert needed.

On Tue, Jan 3, 2012 at 1:38 PM, luis redondo wrote: > I have tried to put in /etc/fstab the following entry for a SDHC card: > > /dev/mmcblk0/media/C589-D18A vfat umask=000 0 0 > > but Ubuntu when boots tells me that the device is not ready to mount and I > was given the > option

Advice from filesystems expert needed.

I have tried to put in /etc/fstab the following entry for a SDHC card: /dev/mmcblk0/media/C589-D18A vfat umask=000 0 0 but Ubuntu when boots tells me that the device is not ready to mount and I was given theoption to skip mounting which I do.The entry is for trying that everybod

Re: F15 installer align filesystems properly for an SSD?

On 08/11/2011 02:46 PM, patrick korsnick wrote: > I recently purchased my first SSD (a 256MB M4) and in setting it up stumbled > across all the writings about tuning SSDs for linux. One of the main things > that > received a lot of attention was the filesystem alignment/erase block stuff. > > O

F15 installer align filesystems properly for an SSD?

Hi all, I recently purchased my first SSD (a 256MB M4) and in setting it up stumbled across all the writings about tuning SSDs for linux. One of the main things that received a lot of attention was the filesystem alignment/erase block stuff. One post I read was that ubuntu's natty installer took

Re: Risks of backing up live mounted filesystems using dump(8)

Chris Adams writes: > A better way is to use LVM. Put the filesystem in question on a logical > volume, leave some space free in the volume group, and then take a > snapshot when you want to back it up. Mount the snapshot at a different > mount point and back it up however you want (dump, rsync

Re: Automatically forcing umount ncp filesystems

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 3 Mar 2010, A. Boggiano wrote: > Please can you tell me how can I mount/umount ncpfs fs without ipx ? Well, enable tcp-ip on netware server if is not already enabled. Then as usualy: ncpmount -S nwserver -A nwserver|ip_address -U nwuser /path

Re: Automatically forcing umount ncp filesystems

> Is netfs enabled? This service usually unmount ncpfs file-systems on > shutdown. Works for me every time. And I do not use ipx but TCP. > My guess is that ipx is down before you system try to unmount the novell > volume. Gabriel, you pointed out the problem: netfs is down! Please can you tell

Re: Automatically forcing umount ncp filesystems

ra/3.0.3-1.fc11 Thunderbird/3.0.3 > X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 > autolearn=unavailable version=3.2.3 > Subject: Automatically forcing umount ncp filesystems > > Sometimes I need to mount a Novell filesystem like this: > > /sbin/ipx_configur

Automatically forcing umount ncp filesystems

Sometimes I need to mount a Novell filesystem like this: /sbin/ipx_configure --auto_interface=on --auto_primary=on /usr/bin/ncpmount -S NAMEBOX -u500 -U cn=ale.ou=tecs.o=foo -Pfoobar -V Vol1 /mnt/Novell/ If I forgot to manually unmount it, the computer hangs at shutdown: I waited few minutes, a

Re: Risks of backing up live mounted filesystems using dump(8)

On Tue, Mar 02, 2010 at 02:40:14PM +1100, Cameron Simpson wrote: > On 01Mar2010 21:30, Mike McCarty wrote: > | Yes, it is. I suspect he meant a files based backup. With > | dump, what one gets is a dump of the file system itself, > | as opposed to the data it contains. With a files based > | backu

Re: Which backup program should one use? Was Re: Risks of backing up live mounted filesystems using dump(8)

Also take a look at star (much the same as tar, but improved) I have been using star with good results. A limitation I found with tar was long filenames, with multiple tapes. Was not supposed to be a limitation, but crashed every time. Best Regards ashley -- users mailing list users@lists.fedo

Re: Risks of backing up live mounted filesystems using dump(8)

Once upon a time, Russell Miller said: > In my experience, a remount can be done on a running system, so I imagine > that > loss of data isn't something designed into that particular operation. > > I've done it successfully on each server in a running cluster of about 50 > when > I wanted to

Re: Risks of backing up live mounted filesystems using dump(8)

On Monday 01 March 2010 08:33:20 pm Jeffrey Metcalf wrote: > > If you put the filesystem of interest on its own partition, then > > ISTM you can mount -o remount,ro that one file system, and it should > > remain static during the backup. All data will still be available, > > though unmodifiable. Cl

Re: Risks of backing up live mounted filesystems using dump(8)

> > If you put the filesystem of interest on its own partition, then > ISTM you can mount -o remount,ro that one file system, and it should > remain static during the backup. All data will still be available, > though unmodifiable. Clearly, one would need to do something like > an lsof to ensure

Re: Risks of backing up live mounted filesystems using dump(8)

On 01Mar2010 21:30, Mike McCarty wrote: | Jeff Metcalf wrote: | > wrote: | > Isn't dump(8) considered a filesystem based backup? Are you refering to something more specialized? | | Yes, it is. I suspect he meant a files based backup. With | dump, what one gets is a dump of the file system itse

Re: Risks of backing up live mounted filesystems using dump(8)

Jeff Metcalf wrote: > wrote: [...] > A file system based backup is a good deal safer. > > Isn't dump(8) considered a filesystem based backup? Are you refering to > something more specialized? Yes, it is. I suspect he meant a files based backup. With dump, what one gets is a dump of the file

Re: Which backup program should one use? Was Re: Risks of backing up live mounted filesystems using dump(8)

I realized a while back that if one's filesystem is a rat's nest, then one's backups will be a rat's nest as well, as will be any files restored from backup. So I devoted a great deal of time to organizing all of the filesystems on all of my computers, and getting rid of stuff

Re: Risks of backing up live mounted filesystems using dump(8)

Jeff Metcalf wrote: > A file system based backup is a good deal safer. > > Isn't dump(8) considered a filesystem based backup? Are you refering to > something more specialized? > > A file system based backup is one that uses the file system to pick up the blocks of a file and store it

Re: Which backup program should one use? Was Re: Risks of backing up live mounted filesystems using dump(8)

On Mon, 2010-03-01 at 16:48 -0600, Rick Sewill wrote: > I've been confused what backup program, dump or tar, to use. > > At first, I was using dump to back up my partitions. I might throw another suggestion in: One of the RAID techniques where several drives are mirrors of each other. Once you

Re: Risks of backing up live mounted filesystems using dump(8)

filesystem to support it? Block reallocation is also nasty with a dump done that way because you may end up with undetected data corruption including leaks of data between uids. With all these issues, it seems like 'man 8 dump' should advise against its use with mounted filesystems.

Re: Risks of backing up live mounted filesystems using dump(8)

Jeffrey Metcalf wrote: > Hi, > > I'm hoping I can start a brief thread discussing the potential risks involved > with backing up live mounted (RW) ext2/3/4 filesystems using dump(8). Here > are the reasons I ask this: > > 1. My understanding is that it i

Re: Which backup program should one use? Was Re: Risks of backing up live mounted filesystems using dump(8)

On 1 Mar 2010 at 16:48, Rick Sewill wrote: Subject:Which backup program should one use? Was Re: Risks of backing up live mounted filesystems using dump(8) From: Rick Sewill To: Community support for Fedora users Date sent

Which backup program should one use? Was Re: Risks of backing up live mounted filesystems using dump(8)

On Mon, 2010-03-01 at 10:29 -0800, Jeffrey Metcalf wrote: > Hi, > > I'm hoping I can start a brief thread discussing the potential risks involved > with backing up live mounted (RW) ext2/3/4 filesystems using dump(8). Here > are the reasons I ask this: > > 1. My u

Re: Risks of backing up live mounted filesystems using dump(8)

Journals make the problem far worse. On restore you will restore a journal log no longer related to whats on the media, then risk replaying it and causing further damage. Block reallocation is also nasty with a dump done that way because you may end up with undetected data corruption including l

Re: Risks of backing up live mounted filesystems using dump(8)

On 03/01/2010 11:29 AM, Jeffrey Metcalf wrote: > Hi, > > I'm hoping I can start a brief thread discussing the potential risks involved > with backing up live mounted (RW) ext2/3/4 filesystems using dump(8). Here > are the reasons I ask this: > > 1. My understanding is

Risks of backing up live mounted filesystems using dump(8)

Hi, I'm hoping I can start a brief thread discussing the potential risks involved with backing up live mounted (RW) ext2/3/4 filesystems using dump(8). Here are the reasons I ask this: 1. My understanding is that it is safest to dump unmounted filesystems to ensure all buffers are fl